Backend language and framework discussion.

[Matt-Hurd]

So far, we've merged in a golang PR which features a sample GraphQL api. Reaching on a consensus as a community is difficult, but at the moment (from my brief perspective) it appears that our community's Golang support is going to be the largest.

I'm wanting to stay impartial here, so I won't be evangelizing any specific language. Let's use this Discussion to discuss the pros/cons of each language with respect to this specific project. If someone has already mentioned a language that you would be interested in contributing in, adding a reaction to their post is helpful. If you have another language that you want to bring up, this is your chance to evangelize it!

[tapioca2k]

I'll be the guy who puts in the obligatory "Python" post.
I think it's very easy to write and is very widely known, so it gives us the widest pool of contributors. Some concerns about scalability were posted in the discord earlier, and to that I would point to its use in production by Google, Facebook, Reddit, Netflix, etc. It's also notably used by Racetime.gg.
I think it would also allow us to get the site up with minimum fuss. In community projects like this one, getting started and making tangible progress is the most important thing. Most don't make it that far.
(Also, selfishly, it's what I'm most familiar with :) )

[JoshSanch]

It seems like most are interested in using Go, but I wanna add some support to Python. The language is a joy to use and the web frameworks are very well-supported by the community. There's lots of available modules and such, and there's a lot of mature solutions available. Even if we use Go, which is likely, I encourage anyone who is interested to give Python a go on something else if they get a chance.

[RageCage64]

Even though I'm in the Go camp, I'll say the concerns for scalability of Python are probably not a reason to vote against it as a tech stack choice. I have never worked on a Python backend at a huge scale, but I don't think we're going to reach the scale where we it's so bad as to decide against Python. Python is also a popular language, so if we value the popularity of the language/framework then Python is a strong option.

[deains]

As tapioca mentioned, I've used Python (specifically Django) extensively to build racetime.gg. But besides that, during my day job I've also been building RockPaperShotgun.com, and you might have a good guess what technology we chose for that. 😉

Python works at scale, provided you treat it right. Django also gives you its REST framework add-on, which is very extensive (although it's also highly opinionated). In Django getting the basic building blocks of a product ready is quite fast, and the ORM especially is extremely useful for projects that involve a lot of connected data.

For best scaling though, you should make sure proper caching and cache invalidation is in place, as this is the best strategy especially when you're dealing with a product which is going to have a lot of inert data. This is true no matter what language you use!

I'm not going to be working on this site, and I agree with Adam's post further below about choosing a system the people doing the work will be okay with. But I thought I'd share my experience, for what its worth, in case it's helpful in coming to a decision. 🙂

[RageCage64]

I am going to add to the Golang hype train.

• Really easy language to read and learn, should not be too large a barrier to entry
• We will be fine without a framework, which means the only learning curve for new contributors is the language itself
• Very good performance in general
• Lots of stuff baked into the language make it a good choice for open source projects (testing built in, formatter, works fine with all manner of text editor options)
• We have 3 (4?) evangelists for it right off the bat including me

However I am of the opinion that it's going to be nicer to start with a JSON API than a GraphQL API. In my experience, GraphQL is very heavy to solve large scale problems that we're not going to have, at least not early. JSON API's are also significantly easier to write tools around, which as far as I can tell is a major goal of this project. If hearts are set on GraphQL then I don't think it's bad per se, I just feel a normal JSON API is a much easier starting point than GraphQL. Either way, I hope our data layer and API layer can be kept logically separate, allowing us an easy way to experiment.

[AdamGaskins]

Hmm. For a prototype of course it doesn't matter, but I feel like for the actual backend we should use some sort of framework. When we really start to sit down and scope out all the features and pages of SRC, I think we're going to discover there's a lot more than we think.

Yes it adds a bit more complexity and boilerplate at the start, but:

1. That perceived complexity pays off dividends in the long run in terms of development speed, ease of maintenance and ability to add new features.
2. If we choose a common/popular framework, the features will be well documented, making it easier for newcomers to join without having to learn the custom framework that we inevitably end up creating

[RageCage64]

As long as the response is in JSON, I'm pretty happy.

Yeah I guess "JSON API" in my post is a misnomer because GraphQL APIs do return JSON, it's just structured differently. So yeah either way we would be getting JSON out of an endpoint.

I feel like for the actual backend we should use some sort of framework.

In my experience this is less common in Go. It doesn't really have a Rails of its own. The closest is Buffalo which is not bad, but in my time in the Go community it's much more common to use a couple tools (like gorilla/mux for routing and GORM as an ORM) and otherwise stick to the standard library.

Your reasoning is sound for suggesting a framework. Buffalo is good, and could be a fine choice for this project (I have not personally used it; anyone who has used it who can chime in feel free). If we go GraphQL, the code for that library will likely be pretty standard to that library's recommendation and alleviate some of the concerns around our work being too custom to learn.

[AdamGaskins]

Ahh, makes sense, yeah whatever allows us to scale well. I've only dabbled with Go, but it would be cool to learn!

[AdamGaskins]

Cool, well since it seems to be the most popular so far, do the Go users want to describe their experience level with Go backend web development?

[RageCage64]

I can start. I'm not a Go developer at my job, but I have been loving Go for personal projects and have written a backend for a website on a small contract job. I am self aware enough to know that this is not terribly impressive experience, but I'm pretty sure the other Go evangelists so far have better experience.

[AdamGaskins]

As someone who has, over the past 10 years, had to maintain a dozen different production sites with varying levels of code spaghetti: I think the specific language we end up choosing is not going to be as important as the quality of the code that gets written in that language.

I would much rather make the decision of stack around the group of core people who will be working on and overseeing the project. If we built the backend in Ruby for example, I've used Ruby before, but I would certainly not be in that core group. I would want at least one person who is a Ruby expert (meaning experience creating and maintaining large codebases at scale) to create/structure the initial framework code, then multiple people who are proficient with the language to be involved with guiding the project, reviewing PRs etc. just making sure the code follows good Ruby practices and doesn't turn into a mess. Even if we initially scope small, we need to be able to grow a ton in the future if this "open source" thing is to succeed! I have been a part of a dozen community projects like this that have died out because there was a lack of clear leadership or enough technical expertise in the specific languages being used :(

Some may object that what I just described sounds like the thing Squiddo was trying to eliminate by starting this project in the first place: one person/a small group of people in control. However as long as we have a good open source license (which I noticed this repo doesn't have yet!) the community is always able to fork and regain control of the project in the off chance that anything malicious were to happen!

TL;DR
I think we should pick a language based on people's expertise and how long people think they will stick around. If we have 1 person with expert language X skills, vs 20 people with beginner-intermediate language Y skills, I think language X is the clear choice. That's just my two cents! I'm super excited to see where this project goes.

(For what its worth, language-wise PHP is my expertise, but it didn't sound like anyone else had experience with that, and I definitely don't have the time to be a primary maintainer)

[Matt-Hurd]

That's basically the reason for this post. The people that respond are likely the ones that will actually work on things. If people care enough, they've probably got enough knowledge to actually do the thing.

[JoshSanch]

To expand on this, depending on how active the development is on this, it would be good to require a certain amount of people to sign off on PRs before merging while a clear group of maintainers is yet to be established. There needs to be some way for the community of active devs contributing to steer design in an agreeable and strong way.

[RageCage64]

+1 especially to:

I have been a part of dozens of community projects like this that have died out because there was a lack of clear leadership or enough technical expertise in the specific languages being used

(I haven't been part of that many, but enough to have the same experience sadly)

For what it's worth, so far in discussions we've seen mentions of people with expertise in:

• Ruby on Rails
• Python (Django/Flask)
• Java (Spring I hope)
• Go (so far this looks like the most popular)
• PHP (might be filling in the blanks but appears to be Laravel across the board)
• C# ASP.NET
• Node.js (although the hatred is strong in the server so far)

Picking tech stacks is hard enough when you're making a startup with a few people, so a large community project with interest like this is going to make the choice rather challenging. There have been offers from people along with myself to start writing Go, so it may so happen that Go just falls into place because of passionate evangelists at the get-go, but I imagine we'll see strong cases for the other options soon enough.

[AdamGaskins]

Oops, that was supposed to say a dozen not dozens of haha.