Today I decided to note and review the principles that was discussed by Malte UBL from Vercel
Scaling web apps is harder than it seems, both technically and in terms of team growth and iteration.
Technical aspect of making the application performant when reaching millions of users is challenging.
He thinks a lot about scaling and just did a talk on scaling frontend app development on react summit:
Here are six essential principles for scaling applications:
- Tear down the barriers
- Make it easier to delete code
- Migrate incrementally
- Always get better, never get worse
- Embrace lack of knowledge
- Eliminate systematic complexity
Now lets deep into each principle:
Principle 1: Tear down the barriers
The first principle discussed in the video is to tear down the barriers that can slow down development. This includes things like silos between teams, slow build times, and manual processes that can be automated. By removing these barriers, teams can work more efficiently and focus on delivering value to users.
Good example : go migrate to a mono repo that could save a lot of times and removes some barriers
Principle 2: Make it easier to delete code
The second principle is all about making it easy to delete code. This means creating a style system where teams can keep their codebase clean and maintainable.
Good example 1: if you use css-in-js or tailwind, because you have co-location of the css with the code you can easily remove the component with high confidence.
Good example 2: data fetching inside of components in NextJs 13
Principle 3: Migrate incrementally
The third principle is to migrate incrementally. This means moving from old APIs to new capabilities in a gradual way, By taking an incremental approach, teams can avoid breaking changes and minimize risk.
Indeed he believes there are only 2 types of migrations:
- incremental migrations
- failed migrations
Good example 1: Next.js 13 app router
Good example 2: trpc
Principle 4: Always get better, never get worse
The fourth principle is all about continuous improvement. Teams should always be looking for ways to improve their codebase and processes, rather than letting things stagnate. This includes introducing new rules for new code rather than migrating old code, seeking approval for code changes.
It also reminds me the uncle Bob sentence about having clean code: โAlways leave the campground cleaner than you found itโ
Good example: introducing lint rules gradually
Principle 5: Embrace lack of knowledge
The fifth principle is to embrace a lack of knowledge. This means being comfortable with not knowing everything and seeking out answers when needed. It also means being willing to ask questions and challenge assumptions in order to improve outcomes.
Some Good examples:
- To reduce any fear of embarrassment, the team establishes an anonymous question submission system
- Encouraging employees to ask dumb questions helps create a culture of openness and comfort by doing it yourself
- Mentorship and Guidance
Principle 6: Eliminate systematic complexity
The final principle is to eliminate systematic complexity. This includes things like versioning APIs and introducing new fields, which can add unnecessary complexity. The speaker proposes using serverless deployment to eliminate this complexity altogether. By simplifying the system, teams can focus on delivering value to users rather than managing complexity.
Good example: versions Skew
original talk: https://youtu.be/tqhLK0Fb5_4?si=Ql-dj-x5w443dEK9
let me know in the comments what's your opinion about these principles and if you have and good examples of each one
All the best
HASH
Top comments (0)