Why MinBase
Almost every app you use stores data somewhere and fetches it on demand. In this course you will build the system that does that, one visible piece at a time, so that you understand every part of it.
By the end of this lesson you will be able to
- Explain, in your own words, what a backend is and which four parts almost every backend has.
- Describe the path a single request takes from an app to a database and back.
- Say how MinBase differs from all-in-one platforms such as Supabase and Firebase, and why that difference helps you learn.
- Explain how the course is organised, so you know what to expect from each lesson.
1. A backend, in one everyday example
Imagine you open a food-delivery app and tap Order. The app on your phone looks like it did the work, but your phone does not know which restaurants are open, and it cannot store your order where the restaurant can see it. Something else has to do both jobs.
That something is the backend. It is a program that runs on a computer somewhere else, and it keeps the data that the app shows. Your phone sends it a short message such as "please save this order". The backend checks the message, saves the data, and sends a reply such as "done". All of this happens in a fraction of a second, so you never notice it.
The app on your phone is called the client, because it is the one asking for service. The backend is the server, because it serves those requests. A client sends a request, and the server sends back a response. Once you can picture that exchange, you can picture most of this course.
2. Six words you need first
The next sections use a handful of technical words. You do not need to memorise them now. Skim this list, and come back whenever a word in a later lesson feels fuzzy. Every one of these is explained again, with an example, in the lesson where you first use it.
- HTTP
- The set of rules that browsers and apps use to talk to servers over the internet. A request names what you want (for example, "the list of candidates") and how you want to act on it (read it, add to it, change it, delete it).
- API (application programming interface)
- The menu of requests that a server is willing to accept. If the backend is a restaurant kitchen, the API is the menu you order from. You cannot ask for a dish that is not on the menu.
- REST API
- A common style of API where each kind of data has its own web address, such as
/candidates, and you use standard HTTP actions on that address. In this course, "API" will mean a REST API. - JSON
- A plain-text format for data that both people and programs can read. For example,
{"name": "Luna"}describes one thing with one property. APIs use it to send data back and forth. - Database
- A program whose only job is to store data safely and let other programs search and change it quickly. It is the "source of truth", which means that when two places disagree about the data, the database wins.
- Container
- A way of running a program in a sealed box that comes with everything it needs. We use containers so that the software runs the same on your laptop as on anyone else's. You will meet them properly in the next lesson.
3. The four parts of every backend
Backends differ in size and in fashion, but if you strip away the details, nearly all of them contain the same four parts. Here they are in the order a request meets them.
- The client. This is what the person touches: a web page in a browser, a phone app, or a desktop program. They all reach the backend in the same way, over HTTP.
- The reverse proxy. This is the single entrance to the backend. It receives every incoming request and decides which internal program should handle it. It can also encrypt the traffic (a job called TLS termination, which we cover in v-b7). Because it stands in front of the other programs, it is called a "proxy". Because it works on behalf of the server side, not the client side, it is a "reverse" one.
- The API. This is the program that understands requests and turns each one into an action on the data.
- The database. This is where the data lives.
Most real systems add some extras. Authentication checks who is making a request. A web server hands out the files that make up the app itself, such as its pages and scripts. Storage keeps large files such as photos. We will add these one at a time later in the course.
One backend can serve many clients. A web page, a phone app and a desktop app all send the same kind of HTTP request to the same API. The backend does not know or care which one is calling. That is why learning to build a backend is worthwhile: you build it once, and every kind of app can use it.
Watch a request travel through the parts
The diagram below shows the full MinBase design. Do not worry about understanding every box yet. Just follow the arrows from left to right, which is the path of a request, and notice that there are only four kinds of box. We will build the right-hand end first and work leftward.
(browser or app)"] --> T["Reverse proxy
(Traefik)"] T --> N["Web server
(Nginx)
serves the app's files"] T --> R["API
(PostgREST)"] R --> P[("Database
(PostgreSQL)")]
4. How other platforms package these parts
You do not have to assemble these four parts yourself to get a backend. Several products package them for you. It helps to know the main ones, because they show what choices exist and what each one costs.
- Supabase is an open-source platform that bundles a PostgreSQL database, an API generator (PostgREST, the same tool you will use), an authentication service, file storage and more behind one dashboard. It is well built, and it is a good choice for many teams. It is designed to cover a very wide range of needs, so it contains many components that a learner never sees.
- Firebase is Google's closed-source platform. It offers its own database (Firestore), authentication and hosting. It is quick to start with, but it does not use PostgreSQL, so moving away from it usually means rewriting how your app stores and reads data.
- A hand-built stack means writing your own API server in a language such as Node.js or Python, and wiring it to a database and a web server yourself. You get complete control, but you write and maintain a lot of connecting code.
These products do not invent a new design. They all assemble the same four parts. The real differences are who does the assembling and whether you can see inside.
5. The MinBase approach
A platform that hides its parts is convenient until something goes wrong. When a request fails, or a bill arrives, or you outgrow a free plan, you have to debug a system that you never understood. Many tutorials have the same weakness: they hand you a finished setup and discourage you from asking what is inside.
MinBase takes the opposite approach. You build the backend yourself, from well-known open-source parts: PostgreSQL, PostgREST, Traefik, Nginx and Docker. Because you add each part on purpose, you can explain it. Because every part is open source, you can replace any of them later without starting over.
Minimal means that each variant does as little as possible, so there is little to be confused by. Transparent means that nothing is hidden: at every stage you can see how a request travels from the client to the data and back.
6. The ten variants
The course is a series of ten variants, named v-b0 to v-b9. A variant is a complete, working backend. Each one adds only one or two new ideas to the one before it. The table below is a map, not a reading assignment. Several of the terms in it will be new to you, and that is expected. Each is introduced in the variant where it first matters.
| Variant | What it adds | The question it answers |
|---|---|---|
| v-b0 | A database and an API generated from it | What is the smallest backend that works? |
| v-b1 | An external network and a named volume | How do I stop my data disappearing? |
| v-b2 | Health checks and restart policies | How do I make startup reliable? |
| v-b3 | Database roles and least privilege | How do I limit what the API can do? |
| v-b4 | A .env file for secrets | How do I keep passwords out of my code? |
| v-b5 | JWT authentication | How does the backend know who is calling? |
| v-b6 | Row-level security | How do I keep each customer's data private? |
| v-b7 | The Traefik reverse proxy and security headers | How do I put one safe entrance in front of everything? |
| v-b8 | Nginx serving a single-page app | How do I serve the frontend too? |
| v-b9 | Python stored functions as API endpoints | How do I add my own logic? |
The course has two reading levels. If you are a student, follow the main text and do each exercise. If you are a junior engineer, also open the amber Why it matters boxes, which explain the production reasoning behind each decision. Both groups can finish the course with a working system.
7. How each lesson works
Each variant lesson follows the same pattern, so you always know where you are. The pattern is based on how people learn practical skills most reliably: attempt something just beyond what you already know, with enough support to succeed, and then check what you have learned.
- Goal and prerequisites. You read what you will be able to do, and what you should already know.
- Build in small pieces. You add one piece at a time and run it after every piece, so you always know which change caused which result.
- Predict, then run. Before many commands you are asked what you expect to happen. Guessing first, even wrongly, makes the real result far easier to remember.
- Break it on purpose. The early variants contain deliberate weaknesses. You will see each one fail, and you will understand the fix because you felt the problem.
- Recap, quiz and a challenge. You check yourself, then try one task with less guidance.
Callout boxes appear throughout. Each type has a fixed meaning and a text label, so you can recognise it even if colours are hard for you to see.
A statement worth remembering, because later lessons depend on it.
The first time a technical word appears, it is defined in a box like this.
The reasoning behind a decision, and what happens in production. Aimed at junior engineers, and useful to everyone.
A common mistake or an easy-to-miss trap.
A hands-on task for you to do on your own machine.
Many lessons also include terminal recordings. They are real captures of commands run against the working stack. You can play, pause and select text in them. They show what your own screen should look like. Your output will usually differ in small details such as ID numbers and dates, and the lesson will tell you which details to expect to differ.
8. Try it on paper
Pick an app you use every day, such as a social feed, a food-delivery app or online banking. On a sheet of paper, draw three boxes in a row: app, API and database. Then write down what you think happens, step by step, when you tap "post" or "order". Which box does each step happen in?
Compare your sketch with this one
Your version will differ, and that is fine. A typical sequence for posting a photo is:
- The app packages your caption and photo into an HTTP request and sends it.
- The API receives the request and checks that you are signed in.
- The API asks the database to save a new row containing your post.
- The database saves it and confirms.
- The API sends a response saying the post was created.
- The app shows your post on screen.
If you had the idea of "a request goes in, passes through layers, and a response comes back", you already hold the model that the whole course builds on. If your sketch had the app talking directly to the database, that is also worth noticing. Later you will see why that is usually a bad idea.
Recap
- A backend stores data and answers requests from clients such as browsers and apps.
- Almost every backend has four parts: a client, a reverse proxy, an API and a database.
- Platforms like Supabase and Firebase assemble these parts for you and hide the seams. MinBase has you assemble them, so nothing is hidden.
- You will build the backend over ten variants, adding one or two ideas at a time, and breaking things on purpose to learn from them.
Further reading
These are primary sources, which means they come from the people who make the tools.
- PostgREST documentation: the tool that turns a database into an API.
- PostgreSQL documentation: the database.
- MDN: An overview of HTTP: a gentle explanation of requests and responses.
- Supabase documentation: to see what an all-in-one platform looks like.