Building Serverless Django Apps

I’ve been building software for three years. I’d categorize my time in four stages.

First, I started building custom Shopify apps for my eCommerce businesses.

Second, I started building React apps with NodeJS.

Third, I started deploying my apps with serverless.

The third time was a breakthrough. It was the first time I could write software without worrying about servers and infrastructure. It meant I could focus on my core app experience and get it hosted in a single click.

But it was still difficult to quickly bootstrap my business logic on the backend.

Then I found Django, which is stage four.

Why Serverless?

Traditionally, deploying software entails owning a physical piece of hardware that it can be run on. In modern times, this hardware is rented a-la-carte from cloud providers like AWS. You visit the AWS console, select a machine with your desired memory, CPU, and operation system, and that machine is instantly available for you to use.

This is a great scenario for instantly having access to powerful compute resources without needing to physically own the servers yourself. However, even though the physical hardware is owned by your cloud provider, you’re still responsible for maintaining the software portion of it. You’ll need to keep the operating system up-to-date. You’ll need to ensure it’s connected to the internet. There’s a lot of mundane work that goes into maintaining it.

In the 2010s, both Google and Amazon launched new products to solve this problem. While having access to arbitrarily powerful amounts of compute power was revolutionary as part of the cloud revolution, Amazon launched a new product to take this one step further.

Enter Serverless.

Serverless is a framework where compute cost is billed a-la-carte and infrastructure is managed by a third-party. With serverless, all backend maintenance is handled by the cloud provider. This includes operating system updates, security patch installs, and automatically scaling your app to more powerful instances as load increases.

And instead of having a server that’s always on (and that you’re always paying for), serverless only charges when your code is actually being run.

While your code still ultimately lives on a server, all the maintenance and upkeep-costs are hidden from the developer.

Serverless has made it significantly easier for me to prototype software. It enables me to maximize my time writing code that delivers value to the end-user. When I prototype new apps today, I spend literally no time worrying about infrastructure.

I write my code, I run a command in my CLI, and that code is instantly deployed to a serverless endpoint that’s ready to be invoked from the outside world. It’s magical.

Why Django?

The more general question, besides Django, is why use an all-in-one web framework in the first place? If creating a web app, you’ll probably need a few things:

  • a router, to specify the URLs in your app
  • a database, to store resources and retrieve them
  • an authentication system, to verify whether a user can access resources from your database

When building an app, you can build each of these services independently using whatever tools you have available. However, a web framework includes them for you, making it really easy to get up and running without needing to make decisions between routers, databases, or auth services.

Django has one main competitor, which is Ruby-on-rails. I’ll say first that I’ve never used Ruby, and I’m sure you can build the same apps as with Django. But Django has great documentation, is written in Python (the world’s third most popular coding language), and has the best SQL-abstraction layer on the market.


Have you ever written SQL before? It’s not very hard to learn basic operations, like inserting a new row into a table, or finding a common field between two tables. But, writing SQL queries outside a SQL query editor is fairly tedious. It’s easy to make mistakes.

cursor.execute('SELECT * FROM users WHERE user=%s;', (user, ))

Writing DB queries in Django is much easier. And compared to other ORMs, longer queries (like joins) are much more concise.

Here’s a query in SQLalchemy:


And the same query in Django:

User = User.Objectives.Filter(address_email_address=email_address)


Another painful step is web app development is deployment.

You’ll need to set up a server, access the server through SSH to get your app running, and make sure there aren’t any weird network rules that prevent it from talking to the other parts of your app. And, if you’re a cash-tight bootstrapper like me, you’ll need to start paying for your server from day one.

I’ve been building all my apps using serverless, because it solves each of these problems entirely. Instead of thinking about servers, I write small blocks of code that I deploy to Amazon with a single-click. I’ve been using a local development server inside a Docker container to test my functions before deploying, so I can write code without having an internet connection.

All my serverless commands live in a Makefile. When it’s time to deploy, I run a single command make deploy-dev, and in a few minutes my API is hosted on AWS and ready to be invoked by the outside world.

The Front-End

The front-end for my web apps has been another important component in building a killer web app framework. I originally had a few criteria for the front-end:

  • React, with Typescript (because it’s 2020, and only plebes are still referencing undefined objects in Javascript)
  • CSS styles (using canonical CSS is more powerful than using the React style system)
  • Authentication

Today, my React template achieves all of these criteria and more.

I’ve finally reached the point where building a Product-Hunt ready SaaS app is less than a day’s work away. Luckily for you, the React app is designed to work hand-in-hand with Django-Serverless.

No matter your experience level with app development, I believe these two templates combined make one of the world’s best prototyping frameworks for modern web apps.

If you haven’t pledged allegiance to a web framework yet, this might be the last one you ever need.

Download Links



Did you enjoy this?

If you've enjoyed reading anything here, you should consider signing up for semi-regular emails from me. That's the first place I go to share anything that's on my mind.