Just Random Coding - Which Back End Should I Use As A Front-End Developer?

Choosing a service to store data can be confusing and overwhelming for a front-end developer. What are all these acronyms? Are the Amazon services named strange on purpose? These and many other questions await your journey into the back-end.

As a front-end developer turned full-stack, I've spent more time than I'd like to admit trying to figure out the backend. Because the backend is harder to visualize, I struggled to understand how the pieces fit together. Luckily, I soon found out I wasn't alone. There's a support group when confused front-end engineers meet called Twitter.

Consider this article a "choose your own adventure" piece. I'll ask questions about your requirements and then present a few options. Before we can begin our journey, I must first explain the basics. You can also jump to the list of services directly.

Backend Basics

What is this scary place, the back-end? You can boil it down to this:

You need a place to store data (database)
You need a method of retrieving the data (API)

As a front-end engineer, you've probably worked with APIs before. They allow you to fetch data from some database, somewhere. On a long enough timeline, you'll eventually need to build your own API or work with an existing codebase that has a back-end. This brings us to our first question.

Do You Even Need a Database?

You need a place to store data, right? Here are some questions to consider:

Can the data live alongside the code?
Can the data be tracked with source control?
Do non-technical people need to modify the data?
Do you need different levels of access?

If you can store your data with your code in source control, you might be fine using Markdown with git – that's what this blog uses. It's also worth mentioning you could use JSON files as a pseudo-database if you fall into this category.

However, you're likely reading this article because you need a database. Before we start learning about how you can create your own backend, you might also consider a low-code solution.

Low Code Solutions

Since you're a front-end developer, you might be able to utilize a low code solution. These low code tools are arguably the fastest way to get access to some remote data.

Common examples include Google Sheets or Airtable as a database. There are other services that provide an API abstraction on a variety of data sources.

Terms To Understand

Okay, so you need a database and it's going to require code. First, I need to explain some terms you'll likely run into.

SQL / NoSQL

A SQL database contains relational data. Consider a social media site with a table for users and posts. Every user represents a row in the users table. Each user can have many different posts. There is a relation between a post and the user. These relations makes it easy to look up different pieces of data through queries.

NoSQL databases are (generally) document-oriented. Unlike a SQL database, there are no tables or rows. Instead, you store data in documents, which get organized into collections. For example, in Firestore each document contains a set of key-value pairs. This is a great option for large collections of small documents.

GraphQL / REST

APIs allow programs to talk to each other. REST and GraphQL are simply two different ways to fetch data. For example, here's a GET request to fetch the number of views for a blog post.

$ curl https://leerob.io/api/page-views?id=databases
 
{ "total": 1234 }

GraphQL is an open-source specification for how to query your APIs. Converting the previous example from REST to a GraphQL query might look like this.

{
  post(id: "databases") {
    views
  }
}

If you want to learn more, here's an excellent resource.

Authentication / Authorization

Authentication verifies who a user is, while authorization verifies what they have access to. You'll commonly see this abbreviated as AuthN (Authentication) and AuthZ (Authorization).

If you're building any application that has users or requires limiting access to certain areas, you'll need to consider both of these.

Hosted / Self-Hosted

Your database can either be hosted (managed by someone else) or self-hosted. When backend services are open-source, it generally means there is an option to self-host.

If you don't want to deal with infrastructure, use a hosted service.

Serverless

Serverless allows you to write and deploy code without the hassle of worrying about the underlying infrastructure. You only pay when your code runs. With a traditional server, it's always running. In general, serverless should have less maintenance. There are, however, tradeoffs.

It's worth mentioning how you deploy your front-end might impact which back-end service you choose. For example, if you use Next.js and server-side rendering, each page generates a serverless function. At a large enough scale, you'll run into issues where there are too many open connections to your database. A common solution for this is connection pooling. For more information, check out Prisma's deployment documentation.

Data Modeling

When learning about databases, you might hear terms like one-to-many and many-to-many. These are ways of modeling your database relationships. Database normalization is how you organize a database into tables and columns.

Levels of Abstraction

Every situation is unique. There are many tools that exist to solve the same problem. By understanding what you're looking for, it will help you choose the right solution. First, let's understand what you're trying to build.

Are you building this backend for yourself?
Will other people need to use it / support it?
Are you trying to build a Minimum Viable Product (MVP)?

Personally, I like to experiment with new technologies when I'm creating personal projects. If I'm picking a tool for my day job, I'll likely default to one that's well-adopted in the industry and has robust support. There's more control picking a backend when you're a solo-founder building the entire tech stack yourself. As you introduce other engineers into the mix, things get more complicated.

If you need something fast, you'll want a higher-level abstraction. These services typically provide a client or API out of the box that reduces the amount of boilerplate code you need to write. This is commonly referred to as automating the CRUD (Create, read, update and delete) portion of your backend.

Let's assume you want something more high-level, ideally with a website or interface to manage your data. If you want complete control, you might consider building your own.

List of Services

I've crowdsourced a list of services you might consider using. Below, I'll give further insights into a few services I know well. The reality is that each service listed here has its own tradeoffs. Hopefully this gives you a high-level overview to research more. It's also worth mentioning the service you already know well might be your best choice. Here's some questions to consider.

Does your backend need to be built on open-source technology?
What level of vendor lock-in are you comfortable with?
Are there are security considerations your company/client has?
How much do you want to build yourself vs. rely on a service?
Do you need social login? (Sign in with Google, Facebook, etc.)
Do you have an existing database you're trying to improve access to?

Backend (as a Service)

These are (typically) managed services that automate the creation of code based on your database schema. You might see these referred to as "in a box" solutions. For example, Hasura provides a GraphQL API in a box as part of the platform.

✅ Yes, or included directly in the platform
⛔️ Not supported or available
🚧 Requires some work

Name	Type	Open Source	Self Hosted Option	AuthN Included	GraphQL
Firebase	NoSQL	⛔️	⛔️	✅	⛔️
MongoDB	NoSQL	✅	✅	✅	⛔️
Fauna	NoSQL	⛔️	⛔️	✅	✅
Userbase	NoSQL	✅	✅	✅	⛔️
PlanetScale	SQL	✅	⛔️	🚧	⛔️
Hasura	Postgres	✅	✅	🚧	✅
Nhost	Postgres	✅	✅	✅	✅
Supabase	Postgres	✅	✅	✅	✅
AWS Amplify	Both	✅	✅	✅	✅

Supabase

Supabase is an open-source alternative to Firebase. But it's really much more than that. If you want Postgres, you'll want Supabase, hands down. They also have authentication, storage, and support for GraphQL.

Hasura

Hasura allows you to create an instant GraphQL API based on Postgres. With Hasura Cloud, it's easy to go from an idea to a live API. I love that you can create your database models directly through their console.

If you haven't looked at Hasura since they've launched their managed service, give it another look. One of the issues I had before Hasura Cloud was cold starts with the Heroku free tier. Hasura Cloud prevents this while remaining on the free tier.

While Hasura generally recommends using Auth0 for authorization, it's possible to roll your own. If you want authentication included with Hasura, consider Nhost.

Build Your Own Backend

These are libraries and tools to build your own API and back-end logic. In general, I wouldn't recommend these for absolute beginners. Personally, I learn best by doing. My entry into back-end development came through building real applications and trying out different technologies. You want some quick wins at the start so you can feel like you're progressing.

When you lose a level of abstraction, there are other pieces you need to consider.

How distributed is my userbase?
How reliable does my database / backend need to be?
What kind of tooling does the solution provide (for example, database migrations)

It's also worth mentioning you can use AWS RDS to self-host any SQL-based database. It's proven technology that even has credits available for founder/startups.

Name	Type	Open Source	Self Hosting?	AuthN Included	GraphQL
AWS DynamoDB	NoSQL	✅	✅	⛔️	⛔️
Prisma	SQL-based	✅	✅	⛔️	⛔️
Prisma + Nexus	SQL-based	✅	✅	🚧	✅
Prisma + NextAuth	SQL-based	✅	✅	✅	⛔️

Honorable Mentions: Laravel, Rails. I wanted to keep this JavaScript focused.

Prisma

Prisma provides an auto-generated and type-safe query builder based on your database schema. It currently supports PostgreSQL, MySQL, SQL Server, SQLite and MongoDB.

If you want to build a GraphQL API with Prisma, you can pair it with Nexus. Nexus has plug-ins for authentication / authorization.

Should You Use a CMS?

A Content Management System (CMS) allows you to manage the creation and modification of your data, which typically includes a database. For example, WordPress might use a MySQL database to store the content. Should you use a CMS or just use a database directly? More questions.

Are you dealing with images or document storage?
Do any non-technical users need to manage the data?
Do you need to localize the data?
Do you need drafts / previews of content (like blog posts)?

If you answered yes to any of those questions, you might want to explore a CMS.

Starting From Scratch

Some (usually more experienced) full-stack developers end up wanting full control over their infrastructure and prefer to work directly with databases. This typically requires a more fundamental understanding of the back-end. There's entire books on this subject, which include the following list of buzzwords.

Don't feel overwhelmed. As front-end developers, we know that we don't need to know everything. Both the front-end and back-end are complex, dense areas. Start small, learn intently, and soon you will be crafting your own APIs with ease.

Conclusion / Resources

Would you change anything? Do you have any resources for learning the back-end? If so, leave a comment below and I'll update this list.

Which Back End Should I Use As A Front-End Developer?

Table of Contents