Yesterday, I lamented that web development hadn’t come to any consensus on tooling. programming language, basic UI framework or anything else.

I was talking about front-end development, but it’s true on the back-end as well.

Here, I’m not so sure if we could ever get consensus. On the front-end everyone is running in a browser and ultimately has to provide HTML, CSS, and Javascript. I was hoping that would have driven the industry towards one obvious choice.

On the back-end, everyone has been using their tool of choice for decades, and using Javascript (via node) is a good choice now, but it’s not close to universal. And if you are only working on the backend there isn’t a requirement to know Javascript at all, so there are lots of teams that don’t care about matching languages.

For me, using one language on both the front-end and back-end is such a compelling benefit, that I’ve moved to node for anything new. In practice, I haven’t had much code sharing, but I am flipping back and forth so much while developing, that just having to have one language in my brain is reason enough.

And since I use GraphQL, again Apollo is an obvious choice.

Before this, I was using Django and Python for my backends, and I like working with an ORM for SQL data, so I decided on TypeORM. Here there seemed to be 1 or 2 other viable options as well. TypeORM can be DB engine agnostic (depending on what you use), so setting up an in-memory, sqlite version for unit testing is pretty easy.

With Apollo and TypeORM, TypeGraphQL is a nice addition. It lets me have a DSL that describes entities in one place that generates my DDL, queries and also encodes them for GQL/Apollo automatically. If you don’t do this, a lot of your GQL code isn’t going to be type-checked.

My backend is essentially just a DB with GQL in front of it right now, so there isn’t much else to decide. Since I use the same language as my front-end, I can use eslint, prettier, and jest here as well.

The one thing I miss from Django is the automatic admin console and user management. In the end, I do think my admin interface needs to be more custom, but it’s useful at the start until you get around to making a real one. I looked at AdminJS, but unfortunately I had already committed to some TypeORM choices that it couldn’t support. If I thought I’d be on AdminJS long-term, I might have backed out of those choices.

In any case, the choices on the back-end mostly depend on what language you choose. As an iOS developer, I never really had the option of using one language for the full stack—I usually want to make native apps and Swift isn’t ready for the server-side in my view. It’s nice to have this option, and would make me reconsider ReactNative if I need a mobile app for this project.