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.
Continue reading about How JAMStack helps you ship
Semantically similar articles hand-picked by GPT-4
- Learn Gatsby and NextJS with my new workshop
- Why trunk-based development is best
- Build better apps faster with the JAMStack
- The mistake that strangles engineering teams
- Scaling teams is a technical challenge
I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.
Subscribe below 👇
Join Swizec's Newsletter and get insightful emails 💌 on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.
"Man, love your simple writing! Yours is the only newsletter I open 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. 👌"
Senior Mindset Book
Get promoted, earn a bigger salary, work for top companiesLearn more
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️