Making Sense of Jamstack & Serverless Architecture Backend

Jamstack
Serverless
Fundamentals

It feels like the modern web has become synonymous with buzzwords. These terms can be confusing and hard to really understand.

Two of these buzzwords are hard to distinguish for some: Jamstack and serverless.

They are two powerful architectures that help developers build great experiences for the web—but are they just two buzzwords without much substance? What do they actually mean, and are they the same thing?

Let's start with the basics.

What is the Jamstack?

Jamstack is an architecture that focuses on two points: serving a website or application statically on request and precompiling or prerendering as much of that experience as possible before the HTML reaches the browser. That experience can even be made dynamic by taking advantage of clientside requests and in-browser capabilities.

This idea was popularized by static site generators and frameworks that would pull together dynamic content to produce a website or application statically. That application would eventually be served straight from static storage.

Bringing together a "mesh" of services

The idea of the Jamstack would grow to include strategic modularity of application infrastructure, where maybe it doesn't make as much sense to build an entire stack of features on one server.

Instead, that infrastructure would be divided into components or microservices where the frontend would be the hub to tie all of these services together, sometimes referred to as the "mesh".

Gatsby's content "mesh" via https://www.gatsbyjs.com/blog/2018-10-04-journey-to-the-content-mesh/

Instead of building a specific component yourself, you could use third-party services like an authentication service or a shopping cart. You wouldn't necessarily need to maintain it yourself, and you can be confident the service will work well.

Building better experiences on the web

Regardless of what mesh of services you use, the goal is to eliminate time spent on a server while the visitor waits for the frontend to load. This directly helps to improve the performance and the UX (User Experience) of the application. This will not only help to keep your visitors but also help with SEO.

It typically also leads to less cost, as static storage is really cheap! And that static storage or static CDN (content delivery network) request can scale infinitely, allowing any number of visitors to hit the core application at once.

What is serverless?

Serverless is an architecture that revolves around the idea that you don't have to "use" or rely on servers in the traditional sense (read: have to build and/or maintain your own server) when building applications. Instead, you take advantage of services typically managed by cloud vendors (AWS, Microsoft Azure, and Google Cloud, etc.) that abstract the server, providing similar capabilities as traditional servers, but in a focused and easy-to-use way.

Compute without the overhead

While technically, everything on the web is running on servers, the goal of serverless is to take away the overhead and maintenance from the developers as if they weren't using servers at all. The cloud provider managing that service is solely responsible for any upkeep typically done with server-based services.

Take a popular serverless technology like serverless functions, for instance, using AWS Lambda. We can run code that would be typically running on a server inside of a "function" without having to touch a server at all.

Just like on the server, that function can make requests, access data, and provide a mechanism to interact with secure resources, but you work within the confines of a single function.

Highly scalable and cost-effective infrastructure

The cloud provider will handle the infrastructure and management of that function. Your goal is to provide the code executed when that function is invoked, like hitting an API that runs that function.

This ends up leading to lower costs, as you only get charged when the function is invoked instead of having to pay for a server constantly running even when unused.

It's also a highly scalable solution. Your functions aren't stuck sharing resources between one or many servers, and their resources are pooled for each invocation.

When a traffic spike occurs, the functions are scaled horizontally, meaning more instances of that function are invoked, as opposed to vertically, where you might have something like a server that would instead just get more resources added to it.

Because you can virtually have as many invocations as you want, that's where the idea of "infinitely scalable" comes into play.

Are Jamstack and serverless the same thing?

Technically no, but it's a bit more nuanced as Jamstack and serverless have a lot of overlap.

Comparison between serverless Jamstack (left) and serverful Jamstack (right). The yellow row is self-managed as opposed to the light gray row that a cloud provider manages.

Like I mentioned earlier, Jamstack came from a place where the goal was to serve your website or application from static storage. This is more so on the frontend of your application, which involves your HTML documents and static assets.

Static storage itself is a serverless solution, as it doesn't include the overhead of maintaining a server to ultimately serve those files.

On the other hand, serverless doesn't necessarily mean you're building with a Jamstack architecture. Serverless typically refers to how you're working with your backend but can also include some of the same key components of a Jamstack architecture.

You may still be serving your application server-side rendered (SSR), but your traditional backend may be using APIs built with serverless functions or serverless databases like DynamoDB.

We can get a good look at the particularities with a few examples.

Let's get practical

Example 1: Jamstack

  • Frontend: React application served from Netlify (static)

  • Backend API: Ruby on Rails server

We're working with a static frontend where the HTML and assets are served without any compute happening on request. The application takes advantage of clientside requests, but it hits a Ruby on Rails web server, which isn't a serverless solution.

Example 2: serverless

  • Frontend: Next.js serverside rendered via Vercel

  • Backend: serverless functions served from Vercel

Our frontend of the application wouldn't be considered Jamstack. We're using a server to render each and every request. That said, once our application is rendered and in the browser, we take advantage of serverless functions to provide additional dynamic capabilities for our application. While the entire solution may not be serverless, our backend API is serverless.

Example 3: Jamstack + serverless

  • Frontend: Static Gatsby app served from AWS S3

  • Backend: serverless functions from AWS Lambda and API Gateway

Similar to example 1, we're taking advantage of serving the frontend of our application statically, avoiding any server rendering upfront on the first HTML request, already making it Jamstack friendly.

In addition, we're using an API that relies on serverless functions, making part of this solution serverless as well!

Bringing together Jamstack and serverless

As I alluded to before, the frontend of Jamstack apps can technically be considered serverless. In examples 1 and 3, we're not managing a server, which makes static storage a serverless solution!

Meaning the frontend of Example 1 is serverless, and the entire solution for Example 3 is serverless but also Jamstack friendly.

While they're not necessarily the same thing, there's a ton of overlap, and when combined are a powerful solution!

What's the future of Jamstack and serverless?

Both architectures provide enough benefits that make them compelling to use each on their own. Whether you're looking to offer blazing fast UIs with the Jamstack or infinitely scalable backends with serverless functions, either way, you're in good hands.

But as each technology grows and matures, we start to see more and more overlap between the two.

Jamstack itself could be considered serverless when talking about the frontend. That goes for the traditional static storage or more experimental approaches that use serverless functions to render that document dynamically.

And serverless doesn't necessarily mean Jamstack, but it fits right in and provides similar benefits to a Jamstack frontend.

While we probably won't see the two become one, we'll likely see more significant adoption of the overlap, making Jamstack and serverless a powerful combination for building modern applications for the web.

About the author

Colby Fayock
Developer Advocate at Applitools

Learning by doing is the best way to learn, and it’s how Colby Fayock helps others learn Javascript, React, and the static web. His work includes technical writing, videos on YouTube, courses on egghead.io, two books including Jamstack Handbook, and a Developer Advocate at Applitools.

Follow him on Twitter!

New to Jamstack? Everything You Need to Know to Get Started

Read next from Colby
View more

Recent articles in Jamstack

36 000+ geeks are getting our monthly newsletter: join them!