Frontends and backends: the restaurants of code#
If you’ve been reading Technically for a while, you know that an application – like the one you’re reading this post on – is made up of just two parts: a frontend and a backend.
The best analogy I’ve thought of for frontends and backends is a restaurant. Say you’re having a lovely evening with the homies (after you’ve hugged and kissed them of course) and you stroll into your favorite upscale Brooklyn eatery. Your experience is interfacing with a few things:
- A nice table with comfortable chairs
- High quality food and drink brought to your table
- Servers catering to your every whim
Fantastic. Behind the scenes though, there’s tons of logistical work that goes into being able to provide you with said experience. In particular, there’s an entire kitchen staff that worries about:
- What should be on the menu
- How to cook everything consistently and perfectly
- Where to source quality ingredients from
- How to prepare and store those ingredients
- What to do in situations where ingredients are missing or go bad
As a patron, you don’t need to think or deal with any of this – you interface with the “frontend” of the restaurant, and the “backend” takes care of making sure the food that arrives on your table makes you want to leave a 5 star review.
It’s not a perfect comparison, but this is pretty much how I think of application frontends and backends.
The frontend’s job is to interface with the user and call upon the backend when it needs any sort of data to provide to the user. There’s a menu of things that the backend can do for the frontend – these are API endpoints – like sending a user’s profile information, creating a new user account, or accepting credit card information. As long as you’re accessing the frontend through your web browser, it can only be written in HTML, CSS, and JavaScript (the browser doesn’t support other languages).
The backend’s job is to take care of all of the data and logistics behind the scenes. It’s consists of the database, API endpoints for interacting with that database, and any other workflow related things like scripts for billing users, data scrubbing for compliance, and other such highly interesting and obscure tasks.
The frontend and the backend of an app are not necessarily separated physically: they’ll often be deployed on the same single server, and even sit in the same master folder (or repository) of code. Literally, I’ve seen codebases with a /frontend folder and a /backend folder.