The JAMStack and the startups building it
As the line between frontend and backend has blurred over the past few years (thanks React), the JAMStack has emerged as a new paradigm for building sites and apps. The stack itself is generally easy to understand, but the ecosystem – tools, plugins, and APIs – isn’t. We’re going to walk through what the JAMStack is, how to categorize tooling, and why modular use case specific APIs are going to continue to grow in popularity.
- API: instead of a monolithic web server, all backend functionality (authentication, users, etc.) is served via APIs
- Markup: your whole site is just a bunch of HTML files served statically
This is like, very different from what most larger apps look like. If you’re accessing a web app like Twitter in your browser, there’s probably a ton of server side logic dictating what you see, how you log in, and everything else that’s custom about your experience. In a JAMStack app, all of that logic would be encapsulated in simple APIs.
These ideas have been around for a while, but the JAMStack concept is definitely having a moment over the past couple of years:
There’s even a JAMStack conference that started in 2018, started by a group of repeat founders from early JAMStack companies (Contentful, Gatsby, etc.) that have continued investing in the ecosystem.
As with everything in web development, JAMStack apps vs. traditional web apps isn’t entirely black and white. Even if you hide complex server logic behind easy to use APIs, JAMStack apps need to have a backend somewhere; and caching and serving files from a CDN isn’t exactly a new idea.
Think of JAMStack less as an architecture and more as a philosophy for where application logic should sit and what best practices for serving sites should be. In that vein, keep an eye out for
Redwood.js – they’re taking aim at a full framework for JAMStack apps complete with an actual backend.
The JAMStack Ecosystem
A is for API
Even if your backend is nice and clean and obscured behind a simple API, application logic has to live somewhere. The serverless ecosystem has been growing pretty quickly: all major cloud providers offer the ability to run functions without setting up a server, like Lambda on AWS. Over the past few years though, hosting providers like Netlify and Vercel have started to support serverless functions as add-ons. They’re both just white-labeling other cloud providers for now, but that could change in the future. AWS's Amplify is lurking (along with ages old Firebase), too.
Another important area of the ecosystem is CMS providers. If you’re running a blog or publication, you’d traditionally need to use a Content Management System like Wordpress or Drupal – deployed on a server – to write and manage your content. For JAMStack apps (or regular apps too, really), newer providers like Contentful and Storyblok expose content through REST or GraphQL APIs so you don’t need to manage any servers yourself. There are a lot of headless CMS solutions out there.
M is for Markup
This is where things get interesting. Probably the biggest story in frontend over the past few years has been the meteoric rise of client side rendering via React, Vue, and Angular. Building componentized pages that interact well with your data model is now more of a science than an art. Alongside these kinds of libraries, a new suite of static site generators like Hugo, Jekyll, Gatsby, and Next.js are making it simpler to go from content to built page.
The last missing piece here is hosting and deployment. Like Firebase did for mobile apps, companies like Netlify offer platforms that simplify a lot of the annoying parts of building JAMStack apps, like a global CDN, automatic deploys, identity and login, and serverless functions. More about them in the next section.
Two types of tools: point and platform
As with pretty much all developer tools, the JAMStack landscape can be split into two basic approaches: do a really good job at one task, or offer a full platform for accomplishing an entire workflow.
→ Point solutions
Most of the tools we covered across the J,A, and M try to be useful for one particular task: Contentful for CMS, Lambda for Serverless, or Hugo for static site generation. You can’t realistically finish an entire project without using multiple of these, and they don’t necessarily integrate well out of the box.
Companies like Netlify and Zeit are trying to build full platforms for building JAMStack apps – they take care of almost everything, from deploy to functions to CMS. Individually, each piece that they offer isn’t going to be the best on the market, or even close to that; but the power of features integrated together can sometimes outweigh shortcomings of individual products (just ask Microsoft). This is part of why Netlify is trying to own the content and narrative around JAMStack sites.
For an exhaustive list of JAMStack related tools, check out the awesome-jamstack repo on Github.
The Future: Use Case Specific APIs
Earlier, we looked at tools like Contentful; they provide a fully managed CMS that gets exposed via an API. CMS is just one well scoped use case – writing and managing content. But the Contentful model is getting a lot more popular as a broader category: SaaS tools that take care of a full piece of a workflow with a very use case specific series of APIs. Here are a few examples of more established ones:
- Algolia – search as a service via configurable APIs
- Auth0 – identity and authentication as a service via API
- Optimizely – APIs for feature flagging and experimentation
- Shopify Plus – headless e-commerce, like Contentful
- Sendgrid – send emails to your users via API
- Stripe – IDK if you’ve heard of them, they’re hiring
These tools have 2 equally important parts:
- A series of APIs to integrate directly into your app
- A frontend / admin panel for visibility and management
These services have nothing to with each other in terms of what they actually help developers do, but they all rely on the same approach of providing value through a narrowly scoped set of APIs (and they’re API first, even if there are frontends) that solve a particular functional use case.
One way of looking at these third party APIs is as a natural progression from JAMStack’s core tenet: couching complexity behind well designed APIs that make actual deployment easy. The next logical step is outsourcing those APIs.
I think this is going to become an increasingly common piece of how developers automate parts of their work. A few newer services I'm keeping an eye on:
- Memberstack – APIs for building and managing memberships
- Getform – APIs for building forms into your site with “no backend”
- Sendbird – APIs for chat and messaging in your app
- Snipcart – API for adding a shopping cart to your site
Some of these services are more infrastructure-y (think Plaid, Algolia) while some are more functional (Memberstack, Sendbird). The common thread is that they need to solve some non-trivial problem (if it’s too easy to build yourself, you will) while still giving developers the flexibility they’d expect from something more custom.