So when do [I] need a separate backend and frontend? I would like to build a [web app] with login, registration, user settings, database usage.
This is a common question asked by newer developers, so I want to give my take on it with a specific example based on this question.
So let’s say you’re tasked with building a web app like Instagram that allows users to make accounts and upload pictures. For an app like this, some of the basic features will include:
- Uploading images
- Viewing images based on users
- Saving a description with an image
- Saving comments and likes for a specific post, etc.
So which of these features belong to the frontend and which belong to the backend? The answer is they all belong to both.
Throughout this post, I will use the account registration feature as an example to explain the separation between backend and frontend. I will also go into detail on how they work together.
Registration on the frontend
When a user first registers for an account, the user goes to a form that asks for an email and a password. If all goes well, the user enters an email, types in the same password they use for every other site (please don’t do this), and presses “submit”.
The backend comes into play both before you get to the website and after you submit the form.
Before visiting a website
Let’s take a step back. Before a user can visit a website, the frontend code for that page has to be stored on a server. The backend stores the frontend code so that browsers can request it based on the route.
So in this example, let’s say the register page is found at
yoursite.com/register. When a user navigates to the
Afterward, the frontend completely takes over and the user can register for an account.
A subtle, but very important step in the process is what happens on the backend when a user goes to a specific route.
Part of the complexity in writing backend logic comes from making sure that the correct page shows up with the data it needs for a specific route.
The details are outside of the scope of this blog, but the important thing to know is that there are several categories of tools that help manage routing problems. The main categories are:
- Static Site Generators (SSGs) -> Gatsby and Hugo
- Server-Side Rendering (aka Universal/Isomorphic Rendering) tools -> Next and Nuxt
- Templating Engines -> pug (Jade), Handlebars, and EJS
I only mentioned a few specific tools, but there is a huge variety of tools to choose from. This can be very overwhelming especially for newer developers, but from a practical standpoint you can either:
- or learn one of these tools based on your project needs.
There are pros and cons to each, but they can all be used to accomplish the same tasks.
Reach out to me on Twitter or shoot me an email if there is a specific tool you’d like me to get deeper into.
So in short, before the user can view the site, the frontend code is first stored on a server. When a user goes to a specific URL, the server decides what frontend code to send to the browser so it can display the site.
After the browser pulls up the site, the frontend code takes over. Now we’re back to the point where the user submits the form.
After submitting the registration form - on the backend
When the user submits the register form, the email and password are sent to the backend. But what is the backend?
When most developers refer to the backend, they are referring to everything that lives exclusively on the server. This will include:
- The application: Code responsible for all server logic
- The database: System for storing data
- The server: The computer where assets (images, videos, etc.), the database, and the application are stored
I say exclusively here because the frontend code is also stored on a server. However, the frontend code only runs in the browser so it is considered separate from the backend.
In the example, the application will be what processes the user account info. The account data will be sent to a specific route and that route will handle validating the data, saving it to the database, and sending a response to communicate whether the data is processed successfully or not.
Processing data, storing values in a database, and sending a response will take some variable amount of time on the backend. During this process, the frontend has to separately determine what to do while it waits.
After submitting the registration form - on the frontend
Once the form has been submitted, the frontend is in a “waiting” state until the backend server responds. Usually, developers will create some type of loading state to handle this transition.
If everything works out well, then users can log in with the new account! If not…it’s back to the server code to fix some bugs.
This post should give you a high-level understanding of what goes into developing account registration on both the backend and frontend. But what about the other features like login, uploading images, and leaving likes and comments on an image?
Send me an email or message on Twitter if you’d like to see another post or example breaking down each feature!