A brief history of the Jamstack
This article was originally published on the Hasura blog. If there are formatting errors in the article below, we urge you to please go to our blog and read it there. Thanks! :)
In the world of front-end web development, the trends are many and the changes are frequent. Every few years some new technological development to the medium has an exponential influence on the message in shape, depth, and availability.
The browser has democratized access to information in a way no other medium could or can. All you need is a browser that (should) adhere to a common approach in interpreting and processing HTML, CSS, and JavaScript, and as long as you are able to access the file, there is no difference between Chromebook or MacBook, Thinkpad or Supercomputer.
JavaScript has become more efficient and expressive. CSS has become more consistent. Browsers have a wider set of integrations with the local operating system, and HTML itself has seen a much-needed semantic update. During this time, as Javascript standardized across the browsers and increased in functionality, the rise of frameworks to act as a bridge between the different browser APIs became the standard way to write modern web code.
However, browsers historically lack some key features that servers have provided. Servers allow for non-blocking tasks. Servers allow for a protected execution environment. Servers are able to run resource-intensive compute tasks in a centralized way – not everyone has a 32 gig workstation at hand. Thus APIs were born as a way for servers to communicate with browsers in an agreed-upon way.
While the browser as a medium continued to evolve. Server utilization and optimization were also developing in parallel. Many companies began to realize that paying for large servers that were always on accounted for substantial costs in both material and maintenance. The idea of serverless compute was born where lambda functions running on hardware tuned for their execution could run one-off tasks with greater predictability in performance and cost. The idea of “serverless” was born where companies could simply hire a function that executed a specific task to run their workload and return the result, often eliminating the need for a self-managed server entirely – instead processes and workflows were coordinated efforts run across a network of task functions, all communicating via API.
With the browser capable of doing ever-more, the cost-of-entry to server-side execution plummeting, and the ubiquity of APIs dominating the service space - a rise known as Software as a Service (SaaS), the market was ripe for a rethink in how websites were built.
Jamstack today
Few terms command as much name recognition share and virality as the idea of the Jamstack. Jamstack as a term originated at Netlify but quickly become a movement. The name has iterated from various forms including JAMStack, and others, but still refers to the same concept. Where websites in the past required servers to compile template code with data and send that as compiled HTML to the browser, Jamstack allowed websites to be built with lean technology, fetching the data from remote services, and calling complex serverless functions from the browser.
In the earlier implementations of the Jamstack, there was an outsized focus on Server Side Generated (SSG) – aka static. A website generator would read template files, add the data, and create a compiled static site that would then be hosted on a cheap web host. These simple websites would then leverage modern Javascript and modern browser features to create rich experiences for the user, though the content was still static in the end.
Today, Jamstack can cover a lot of different use cases from statically generated sites to serverless sites serverless-sites that still offer the benefit of a server-side execution environment. Choosing the right pattern will depend a lot on the kind of workload you intent to run with your website.
Jamstack patterns
Modern Jamstack websites tend to fall into one of three buckets. Server Side Generated, Server Side Rendered, or Hybrid.
Server Side Generated (SSG)
Server Side Generation, as discussed above, offloads the compilation of template plus data to a build time step. Instead of being generated on-demand, requiring a server to do so, you could build all of it ahead of time, as the majority of website pages, if not the entire site, don’t actually have frequently changing content. Think of this performance like hyper-aggressive caching.
When to use SSG
If your website content doesn’t frequently change, or changes could be more or less predictable for triggering new builds. This may require your CMS to have support for triggering webhooks on updates.
Server Side Rendered (SSR)
Server Side Rendered is a relatively newer pattern in the Jamstack and, as the name implies, rendered content on each request. This offers the most amount of customization with the least amount of code.
Personalization
There are many personalization tools out there that will show visitors tailored content, but for static sites, all that content still needs to be delivered on pageload. With SSR, that content can simply be omitted.
Protected
If your page should be hidden behind a protected environment, you can perform authorization checks on the server, and send the client the appropriate response.
When to use SSR
If your website has thousands of pages, or protected routes, SSR might be a great fit for you. If your page content updates frequently, such as in cases with lots of content teams editing and updating articles, products, or more, SSR would also be a great fit.
Hybrid
This approach is not available to every framework, but it offers the ultimate flexibility. Provide a combination of both server-side rendered and server-side generated content to handle the widest range of workloads. If you have a page that constantly updates, like a home page, choose the rendered paradigm, if you have a popular article that receives thousands of views per day, choose the generated paradigm.
When to use Hybrid
Hybrid will always be the best choice – if your language stack supports it. Not every framework is capable of offering SSR (a space heavily dominated by the Node runtime), and so not every framework will support Hybrid. If you have a language that offers a Hybrid framework to work with, this would be a great choice to look into.
Building a Jamstack toolbox
With the considerations mentioned above, here is a guide to identifying your Jamstack stack.
Identifying your Jamstack components
When working in a serverless friendly way, identifying the services you need to integrate with is the first step. Some good questions to ask yourself.
Is my website asset-heavy?
If it is, you’ll benefit from a CDN to deliver cached, and customizable resources.
Do I need authentication?
Add an auth provider. Choose one that will integrate with modern web frameworks.
Do I need custom data?
Pick a back-end provider. Ideally, you’ll want one that lets you orchestrate some of your services without too much fuss so you have less overall API surface area to fiddle with.
Do I need to run custom business logic?
You will need a FaaS provider. Business logic is different from business “tasks” such as booking appointments, for services like calendering, lead capture, etc – a good SaaS provider would be the place to look in the Jamstack approach. If you need to channel those leads based on arbitrary inputs, then this would qualify as business logic. A stable FaaS is able to handle many different kinds of tasks like this.
Identifying your business type
Jamstack works for companies of all sizes these days. While the remainder of this article will focus on indie developers or small teams, large enterprises benefit just as much from the majority of the content in this article. The only exception is in terms of a service provider where procurement will play an important role in which services are allowed.
Generally speaking, identifying any service provider constraints before any of the remaining stack identification processes will help narrow the scope of available options. Highly regulated or otherwise restricted environments should look for a vendor that offers self-hosting, open-source, or every kind of fortune 500 logo on their website to ensure a smooth flow through the procurement process.
Choosing a framework
Picking a solid website framework will depend largely on the pattern you’ve chosen, the host you choose, and the language you are comfortable working with. An opinionated position of this author is that a Javascript framework will yield dividends in terms of time-to-market as the final compilation of the project will end up in some form of HTML, CSS, and JavaScript, so reducing the amount of compilation and transformation will help ensure your framework stays current for a long time to come.
Some excellent Javascript frameworks worth looking at today are:
AstroJS
Astro focuses on lean development. The idea is to let HTML and CSS hold their own in the Jamstack, which is a stark contrast to many of the frameworks out there.
GatsbyJS
The name that built a thousand sites, GatsbyJS can nearly single-handedly take the credit for getting static site generation into popular developer culture. Where many, this author included, were extolling benefits of Static sites to our nerdy friends, Gatsby somehow got static sites a seat at the table. The framework itself has progressed drastically since its first inception and it handles a wide range of use-case, though static is still core to its DNA. A unique selling prop for Gatsby is the content graph, where a rich ecosystem of plugins can source content from nearly any modern data source and render that content to the page. If you like plugin culture, Gatsby has a lot to offer.
NextJS
NextJS is the workhorse of the JavaScript developer. Handling Hybride site structures, NextJS essentially defined the category of hybrid frameworks. NextJS offers rich abstractions for common use cases but leaves the majority of the opinion to the wayside and lets developers write applications that fit their workload. NextJS is also written by and maintained by one of our recommended hosts and as such, maintains lockstep with at least one friction-free deploy target.
NuxtJS
Nuxt is NextJS for Vue. And that’s a compliment. With all the benefits of the NextJS blend between sensible convention with plenty of configuration, but available to the VueJS audience, Nuxt has a lot to offer with the addition of a very clean API.
Remix.Run
Remix is the newest entrant on the list but is written by and maintained by an incredibly talented team. RemixRun looks to take the power-feature concepts of NextJS and build on them with an alternative set of abstractions and benefit from being able to start the inspiration gathering from the delta position of many years of category maturation. Nested Routes are of particular interest.
Sapper
Sapper is is SvelteJS’s take on NexJS. What makes Sapper unique is Svelte itself - which aims to lean heavily into blazing fast compile times for a generated pattern. Worth noting that the creator of Svelte (and Sapper) has been hired by the team behind NextJS to work on Svelte, boasting good things for the framework and framework diversity as a whole.
Choosing a FaaS provider
FaaS providers handle the business logic of your code. We’ve gone into some explanation of why you’d want to do this above, but the fact is, this is where the 90% use-case of needing a server is handled. We’ve written about different FaaS providers here at length. Embracing this pattern lets you write domain code and less boilerplate code.
Some FaaS providers worth looking into:
FlyIo
FlyIo specializes in creating one-off services (databases, functions, etc) and deploys them to edge locations. They require a higher degree of technical aptitude but offer a high volume scale for relatively low onboarding effort.
Cloudflare Workers
Cloudflare Workers is similar to FlyIo in terms of technical acumen required, but what’s interesting about Cloudflare is that it brings additional services to the table such as their flagship service, being a CDN. With a little know-how, deploying to workers again requires considerably low onboard effort.
Vercel
Vercel benefits from a tight coupling between the framework they provide (NextJS, now also SvelteJS), and their function hosting service. The integration is so good that you can define your functions under an API path of your NextJS projects and they’ll simply work as a traditional API endpoint, though technically are a service worker.
Netlify
Netlify is the most “platform complete” provider on the list. They provide not only excellent hosting, but they offer “speciality” function handling for form capture, authentication, and more. Similar to Vercel, they offer IAC through a .toml file that can be included in the core deployment, which then maps to a functions folder in your codebase, allowing you to benefit from local development as well as automated deployments.
Autocode
The first of our low-code entries on the list. For popular services together, Autocode (formerly Standard Lib) takes out a lot of the pain. It’s difficult to prototype faster than with Autocode for FaaS execution.
Pipedream
Pipedream is our second low-code provider that abstracts away a lot of the boilerplate and provides robust logging, error management, and smooth, versioned, deploys. Pipedream has very low warmup times for a low-code tool and can be used for production workloads.
Choosing a host
Hosting your Jamstack app depends a lot on which platform you intend to use, and in some cases, which framework. If you use Gatsby, you have access to Gatsby Cloud. If you want the best NextJS experience, you’ll use Vercel. If you want the widest flexibility with the easiest deployment strategy and some additional services like auth, then Netlify is the best choice. Though none of these are exclusive.
Gatsby Cloud
Gatsby Cloud gets a node because GatsbyJS is still very prevalent in the ecosystem. If you are in the Gatsby ecosystem, enjoy the Gatsby Cloud if it handles your use case.
Netlify
Netlify handles additional services like auth, form handling, workflows, and more. As with the three other providers on this list, CI/CD deployment from Github is a game-changing functionality.
Render
Render provides a lot of the services a Jamstack site would need. From CI/CD deploys, to one-click database launches, Render is well worth a look for their predictable pricing model and full-featured offerings.
Vercel
Vercel handles all the behavior you’d expect from a modern web host, and offers excellent integration with NextJS for obvious reasons. If you are looking for the smoothest NextJS experience, you don’t need to look much further. You’ll be on your own for auth and form capture, though.
Choosing an auth provider
If your stack needs authentication, there are a number of good providers available.
Auth0
Auth0 is the heavyweight that can do everything. If you’re looking for a well-vetted solution, Auth0 is a great choice. After recently acquiring Otka, they’ve only increased market dominance.
Clerk
Clerk offers first-class support for React-based frameworks along with very simple APIs and elegant user management panels.
Firebase
Firebase doesn’t need much introduction these days, it’s a quick, can-do integration that plays well enough with others. We’ve kept the other “big-tech” providers off this list such as Incognito, but Firebase is such a ubiquitous auth provider it gets a mention.
Magic Link
Magic link wins the “one thing well” category for providing dead-simple, passwordless authentication with generous pricing. If you want an extremely simple provider, have a look.
Choosing a CDN
Depending on what you are delivering, a good CDN will save the launch day. Two worth noting.
Cloudflare
For a general-purpose CDN that will give your sight robust protection against DDoS (intentional or not), Cloudflare is a great choice for delivering your simple static content.
Cloudinary
For delivering images from a powerful CDN that also offers image transformations and a host of other features, Cloudinary is about as simple as it gets.
Choosing a Backend
Orchestrating all of these different FaaS providers, pulling data onto the website, protecting your data, and rate-limiting excessive usage is a critical component to manage when looking into a Jamstack site.
Hasura will manage all of those pieces for you. You can connect your FaaS providers to your API, protect them behind access controls, leverage built-in caching, and more by using Hasura Cloud. With one-click deployments of Postgres on Heroku, you can deploy, design, and access your data in less than 5 minutes.
TLDR;
Jamstack support all kinds of workloads thanks to the rise of serverless computing and a rich, SaaS ecosystem. Jamstack sites help you build faster, more affordable websites with less effort, and are quickly becoming the default way to a modern experience on the web.
Top comments (0)