Swizec Teller - a geek with a hatswizec.com

    How JAMStack helps you ship

    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.

    JAMStack is like frontend microservices

    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.

    It stands for Javascript-Apis-and-Markdown.

    You build the frontend in Javascript, connect to APIs, and use Markdown for content-heavy portions. Easier to write that way trust me :)

    Shift your mindset to the JAM

    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.

    How the JAMStack helps

    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

    Wait what?

    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.

    It's great.

    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

    Did you enjoy this article?

    Published on October 27th, 2020 in

    Learned something new?
    Want to become an expert?

    Here's how it works ๐Ÿ‘‡

    Leave your email and I'll send you thoughtfully written emails every week about React, JavaScript, and your career. Lessons learned over 20 years in the industry working with companies ranging from tiny startups to Fortune5 behemoths.

    Join Swizec's Newsletter

    And get thoughtful letters ๐Ÿ’Œ 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. ๐Ÿ‘Œ"

    ~ Ashish Kumar

    Join over 14,000 engineers just like you already improving their careers with my letters, workshops, courses, and talks. โœŒ๏ธ

    Have a burning question that you think I can answer?ย I don't have all of the answers, but I have some! Hit me up on twitter or book a 30min ama for in-depth help.

    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

    Want to brush up on your modern JavaScript syntax?ย Check out my interactive cheatsheet: es6cheatsheet.com

    By the way, just in case no one has told you it yet today: I love and appreciate you for who you areย โค๏ธ

    Created bySwizecwith โค๏ธ