Yesterday we talked about a common problem in engineering teams: Stepping on each other's toes.
You want to ship a feature but Alice's bugfix isn't ready and your code is mixed. Now you're waiting ...
One solution is trunk-based development with feature flags. Everyone works off master and hides their code behind a gazillion if statements.
You'll need a strict unit and integration testing discipline, a system for feature flags, engineers who never break things, strong typing, good documentation, and the Beyonce rule: If you liked it you shoulda put a test on it.
Anyone might change anything at any time.
Trunk-based development works for Google, Facebook, Apple, and other giant enterprises.
You and me ... eh I dunno. I've seen mixed results and crying users.
Another solution are microservices.
You split your app into areas of interest, known as concerns. Each becomes its own independent piece of code. Ship when it needs to, run its own environment, have its own versions, use its own libraries.
This worked for Amazon. It's why AWS has so many products. Others followed suit.
With this approach teams can iterate independently. Shared code goes into versioned libraries, specific code goes into versioned services.
Alice never has to wait for you and you never wait for her.
JAMStack brings this to the frontend and it's amazing my friend.
Your first separation of concerns comes from splitting the frontend and backend. You've seen this with SinglePageApps.
React, Vue, Angular, etc. apps are built this way. Render your UI in the browser, call the server through an API.
Backend and frontend can iterate independently. Great.
You run into issues as your frontend grows.
Should engineers build the marketing page? Landing pages for specific ad campaigns? Should they help with every tiny tweak and marketing A/B experiment? Even when there's 50 per week?
Don't have enough work building the product? 😉
There's your first split: Product vs. marketing parts of the frontend.
Yep, they want to look the same and share styling. Yes marketing wants a lot of the same API data as the product. Oh yes, the signup widget needs to create users and there's a Login button.
But marketing and product fundamentally evolve at a different pace.
Another fun one are admin interfaces and internal tools. Needs all the same data, moves much slower. Ain't nobody got time to polish those.
Here's what you do to solve those problems: Split your app.
You build a core library for shared features. Start with the design system. You'll need that everywhere and it's easy to split off. A library that gives you perfect-looking UI off a napkin sketch.
Then you create separate JAMStack apps per area. One for marketing, one for admin, one for each internal tool, one or two for the core product ... it depends!
Every app uses the same core stack:
- your design system
- your shared libraries
- your APIs
When admin creates a user it calls the same API as the SignUp button on the marketing homepage.
And despite that, every app is independent:
- its own deploy frequency
- its own versions
- its own deploy environment
- its own staging and preview
Yep. They're independent apps. You can work on each area of your overall product separately. Alice doesn't care what Bob is changing. Neither worries about your changes.
Plus modern tooling gives you a fantastic preview and deploy experience. Every pull request becomes its own live URL. Share it with designers and PMs and they see where you're at.
Feedback early and often. Don't even have to wait for someone to approve your pull request. Show it off before merge 😍
When's a better time to hear "That button doesn't work, make it blue and change the text": 2 weeks after pull request got merged, or 5 minutes after you typed the code?
I know my answer.
PS: tomorrow I'm sharing something new, stay tuned
Here's how it works 👇
Then get thoughtful letters 💌 on mindsets, tactics, and technical skills for your career.
"Man, love your simple writing! Yours is the only email I open from marketers and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌"
Ready to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz components your whole team can understand with React for Data Visualization
Curious about Serverless and the modern backend? Check out Serverless Handbook, modern backend for the frontend engineer.
Ready to learn how it all fits together and build a modern webapp from scratch? Learn how to launch a webapp and make your first 💰 on the side with ServerlessReact.Dev
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️