Means To A Backend

A friend and I were working remotely for a month and wanted to build a product. As software engineers, we could hire ourselves as free employees (self-funded seed round?).

In my last post, I talked at length about how we brainstormed and collaborated to find the perfect idea. When we finally picked one, it was time to decide what our tech stack would be.

For the frontend, it was a no-brainer - we’d use React and Typescript. We’re both experienced in it and it’s a good solution for most problems.

But then it came to the backend. There are so many good options, each with tradeoffs depending on what’s being built. So let’s start by defining what requirements are for our backend.

Requirements

The most important factor for us was that the ramp-up time was as minimal as possible. Most products fail because they can't find product-market-fit. We wanted to minimize the time it took us to get assumptions tested. Another similar requirement is that we needed to use a tool that would allow us to pivot. We figured no matter how good our idea is, we’re likely gonna need to change directions at some point.

We also needed a language that was easy to hire for. If we build this out and see it grow, eventually we’ll need to bring people on. If this is the case, we need to pick a language that has a large talent pool.

We also needed a language that was performant. It needed to work now but also needed to work in the future if/when things got larger. Our app is largely read-heavy and not terribly complicated but that could change.

There were a few more requirements but these were our main concerns and what we tried to optimize for.

Our Choice

Our first thought was maybe to go with Node as we’re both versed in JavaScript. It would simplify our stack, be easy to get going, and has plenty of potential people to hire. The issue is that Node is a backend runtime environment for JavaScript (a frontend language).

It’s not natively built to be a backend language and there are a few wonky issues. One example is it doesn’t have great support for large numbers (you need a library). Also, the number of large projects built with Node isn't as large. It's still not used for many production-level projects. The application could definitely be built with it but we decided to pick a better option.

We wanted a backend first language. Given our constraints and what skills we had, a clear winner quickly popped out. We’d use Python due to its wide use, an abundance of packages, and proven production capabilities. It’s used to power Instagram, Spotify, and Box. Our app is simple, it would work great. Next was to pick a library/framework.

Library/Framework

When it comes to Python backends there are two dominant players: Django and Flask. Django is the largest with the most projects and being around for longer. It’s like Spring, Rails, Laravel, etc. It’s all about the MVT/MVC (Model View Controller). It's built for your typical templated CRUD (Create Read Update Delete) app. It can also be modified to be optimized for a REST API. Django has so much built into it and a pattern of how things are done. It's heavy, and relatively speaking, doesn't have that much flexibility. But it works extremely well.

Flask is the opposite, it's a super lightweight framework. It’s up to the developer to make design decisions and is super flexible. It’s a pretty great option for small projects. As projects grow, Flask apps start to look more and more like Django apps (but with a lot more work).

The last player on the scene is quickly growing and it's FastAPI.

As you can see above this is the fastest-growing Python framework. It’s ultra performant, with speeds close to Golang. Part of this is due to having an async request flow like Node but with the performance of a true backend language.

Fun fact: Python is a compiled and interpreted language

We dug in some more and it seems like FastAPI was super easy to use and had a ton of support. Given that it was lightweight, fast, and optimized for creating APIs it made a ton of sense to use it. No matter how we pivoted it seemed like a great pick.

We paired FastAPI with Postgres and the ORM (Object-relational Mapping) SQLAlchamy. Like anything new, there is a learning curve but so far we’ve found it to be great. OpenAPI is built in which makes for dynamically generated docs. It makes integrating with the frontend that much easier.

Here is a Replit with a basic model using SQLAlchamy. Here is a great boilerplate which sets up your FastAPI repo properly.

Conclusion

I don’t think there is a “best” choice for a backend language and framework. It’s all about using the right tool for the job. Python and FastAPI are great so far and I’m excited to ship a product using these new tools learned.

More to come on the project!