Week 5?
need to see if we can make a project that they can work on
So far, we talked a lot about frontend and backend as seperate pieces. The frontend is what the user interacts with, and the backend is what handles logic, data, and communication behind the scenes.
This week, we are taking a step back from focusing on just one thing. Instead, we are going to look at the whole system and how all the pieces connect.
What is system design?
System design is just the process of thinking about how an application works as a whole. When we build an app, there are a bunch of questions beyond "How do I code this?"
You have to answer
- What parts does this app need?
- What does the data look like, and where will it go
- How will the frontend interact with the backend
- How do we deploy the app
- What happens when tons of people use it
Answering these questions is pretty much what system design is. It isn't just for big companies or complicated apps. You have probably "done" system design if you've ever worked on a project, because anytime you have a frontend, backend, database, auth, file storage, or deployment, you implemented a system.
Thinking in System Design
The best way to think about system design is to break an app into pieces (and break each piece into smaller pieces if you can)
For most web apps, you usually need
- Frontend
- Backend
- Database
- Storage
- Authentication
- Hosting / Deployment
Not every project needs all of these, but these are the most common things most projects have.
For example, with DuckLink, they have
- A frontend where students browse events
- A backend that handles the requests
- A database that stores the event info
- Authentication so students can log in
- Hosting so that the app exists somewhere people can access
Once you think about apps like this, it becomes much easier to understand what you need to build
Usually, projects go through three primary stages during development: the local development stage, the deployment stage, and the scaling stage.
Local Development
This is where everything runs on your computer. You typically have
- A frontend running locally (npm run dev)
- A backend running locally (npm run dev)
- A database running locally (Docker containers)
At this stage, you just want to make sure the app works properly
Deployment
Once your app runs properly locally, it needs to be hosted somewhere so people can access it (Either on the internet or an App Store). This means you need to think about
- Where does the frontend live
- Where does the backend live
- Where does the database live
- How can they all connect
Once a project gets deployed, system design matters a lot more because the app isn't just running in one place, its running like a system (system design).
Scaling
Let's say your app had tons of users showing up. Tons of problems will also start showing up. Things that were fine can become bottlenecks. Let's say
- The backend might get too many requests
- Your site gets so much slower, especially if you rely on the backend to get data.
- The database might slow down under load
- Similar to the backend getting too many requests, anything that requires retrieving information will take a while because your database is overloaded
- File uploads might become expensive
- This can be applicable to the frontend and backend too, but let's say you hit the limit on your free plan for your file server. You will no longer be able to upload anything without paying, which, if scaled up to tons of users, can get expensive.
- Users far away from the server have a slower experience
- Let's say you deployed everything to an American server. Users anywhere else in the world will have a slower time on your app because they have to interact with American servers to get everything. This takes a while, and while not as impactful as the other issues, is still important to consider
This is where ideas like caching, CDNs, load balancing, and horizontal scaling matter. To further show this, lets take a look at an example
The Youtube Example 😁