Jamstack: a deep dive

Compared to the static web pages of the early days, today’s web has come a long way in terms of content served to users and the technology used. Websites of the past with a handful of pages delivered via a Content Delivery Network (CDN) have expanded to using backend servers, databases, dynamic content, and myriad other technologies to provide users a better experience while solving problems that arrive with ever-increasing demand. With all these changes, modern web development has grown to be an incredibly sophisticated field.

Perhaps, it’s a reason why the emergence of Jamstack, which talks about returning to the simplicity of the early days, has become a baffling concept to some developers. Is it possible to bring back the days of delivering static web pages via a CDN when the web has already gotten so complex? How can it provide the performance and functionality of already established stacks like LAMP and MERN (more about these below).

To find the answers to these questions, we have to look a little deeper into what Jamstack is and how it compares with traditional stacks like LAMP and MERN on different fronts.

The JAM in Jamstack refers to combining Javascript, APIs, and Markup as core technologies to develop web apps. However, the term has a more specific meaning which can be summarized like this:

Jamstack is the technology stack used to deliver fast and secure web apps to users by pre-rendering pages and serving them from a CDN, eliminating the need to manage servers.

As mentioned at the beginning of the article, Jamstack is an attempt to bring back the simplicity of the static web by using two main principles.

The first is prerendering. It refers to the idea of generating as much web page markup as possible during the site build time so that the content can be directly served via a CDN. It eliminates the need for setting up backend servers and other complex configurations associated with it—like managing clusters/nodes, implementing security measures, and caching—to serve dynamic content at user request. As a result, Jamstack websites can load faster and serve a better experience to users. The removal of backend from the picture also makes Jamstack websites more secure simply because it exposes fewer components to the outside world.

The second main principle behind Jamstack is decoupling. With the introduction of powerful frontend frameworks to the market, the line between the frontend and backend is gradually becoming blurry. Inevitably, this has led to increased complexity in frontend development. In the Jamstack, decoupling looks to reestablish this clear divide between the frontend and backend by outsourcing backend tasks to third-party APIs and services.

Preferring pre-rendered web pages over dynamically-rendered ones, however, doesn’t make Jamstack a bad candidate for building dynamic websites. This is where the Javascript and API parts of the JAM backronym become important. Jamstack websites use third-party APIs to dynamically load data through requests made via client-side Javascript or serverless functions.

The reason why Jamstack has been able to bring back the simplicity of earlier websites, without losing the advanced functionality supported by traditional stacks, is the ecosystem that surrounds it. The components of this ecosystem have grown independent from Jamstack in the last decade. But now, combined together, they have formed a stack that lets us build faster, secure, cheaper websites.

Jamstack ecosystem primarily consists of the following components:

• CDNs: Recently, many CDN providers catering to Jamstack websites have emerged, like Netlify and Vercel. Deploying a website to these CDNs is simple as connecting the hosted Git repository. The integrated CI/CD workflows of these platforms automatically trigger builds whenever new commits are made.
• Static Site Generators (SSG): The popularity and abundance of SSGs like Next.js, Hugo, Gatsby, and Nuxt in the past couple of years support pre-rendering web pages at build time.
• Third-party APIs: Mass availability of third-party APIs like Auth0 for authentication, Stripe for processing payments, and Algolia for searching allows us to outsource previously backend-bound tasks and abstract their complexity.
• FaaS (serverless functions): Serverless functions help Jamstack websites to integrate heavy logic without calling for backend servers.

• Built with mostly pre-rendered markup, Jamstack sites load faster on the client-side.
• Having no backend servers to protect makes the sites more secure.
• Because they are stateless, the websites can scale on-demand without needing special server configurations or code changes.
• You often only have to pay for the resources you use and nothing more.
• With no backend to configure, you can host your entire website on Git and impose end-to-end version control.

To understand this point even better, let’s compare Jamstack against two of the most popular traditional stacks on the web, LAMP and MERN.

Proven against the test of time, LAMP has been a go-to technology stack of web developers for more than a decade. Even the most famous app on the web, WordPress, runs on LAMP. The four letters in LAMP represent four open-source components that make essential contributions to running dynamic web apps.

• Linux operating system.
• Apache web server for processing client requests and HTTP routing.
• MySQL database for data storage and querying.
• PHP for handling internal logic and serving dynamic content.

Today, LAMP is supported by a mature and extensive ecosystem that supports building robust dynamic websites for any kind of use case. Its completely open-source architecture gives developers full control of their sites with no fear of vendor lock-in.

Despite these positives that have popularized LAMP in the development community, when compared against newer technology stacks like Jamstack, LAMP comes with too much complexity and too little flexibility for modern-day websites.

• LAMP stack has a steep learning curve when learning to configure the backend for everything to work together. Beginners, especially, find this process too complex and cumbersome.
• Dynamically processing and rendering content at request time reduces the app performance from the user's perspective.
• LAMP doesn’t scale easily with high traffic without manual intervention to add more server power, caching layers, and optimized code.
• With all the backend configurations that cannot be automated, implementing CI/CD workflows for the entire website is not practical.

Compared to LAMP and Jam, MERN is an open-source web development stack still in its early days. However, due to its relative simplicity and scalability, MERN has become immensely popular among developers in the past couple of years. It provides a full-stack solution to web development that consists of four main components:

• MongoDB, the NoSQL database
• Express.js, the backend development framework
• React, the frontend development framework
• Node.js, the Javascript runtime environment for backend

The introduction of Node to the backend gives developers the comfort of working with Javascript on both frontend and backend without having to learn another language. The use of Express and React frameworks also abstract away some of the complexity of backend and frontend configurations compared to the LAMP stack.

However, MERN is still tied to the burden of backend, namely dynamically processing content at request time at the cost of site performance. It’s also an ill-fit for working with highly relational data. Though replacing the non-relational MongoDB in this stack with a relational database is a solution to this problem, Node still lacks ORMs that are advanced enough to support complex queries. This results in developers having to manually write SQL queries, increasing the complexity of the development process.

The original philosophy of Jamstack recommends outsourcing database-bound tasks in a web app. Yet, this is not something that’s always attainable or practical. It’s easy to find yourself in situations where you need control of how your data is stored and accessed for functional, legal, or security reasons. But using a traditional database with Jamstack diminishes its initial benefits like increased performance, security, zero-configuration set up, and end-to-end version control.

That’s why we developed Xata to bring the best of both worlds to developers. As a connectionless relational database, Xata is delivered as a lightning-fast and highly available API that Jamstack websites can query from the client-side or through serverless functions. It’s the first-ever database to support the development workflow with version control features like branching, previewing, testing, and merging changes. With these features, Xata gives back the ability to fully automate the CI/CD workflow as Jamstack promises.

Xata also removes a lot of inconveniences tied to traditional databases like scaling, caching, maintenance, security updates, and downtime handling, making it accessible to even those without development experience to build and deploy their own apps. With the addition of Xata, Jamstack becomes an even more powerful way to build websites that makes the lives of users and developers a lot easier. It takes you back to the simplicity of the early days of web, while retaining all the breakthroughs this field has made in the past two decades to serve users a better experience.

We're currently in private beta, so if you'd like to get started with Xata today, sign up on the home page, or @-us on Twitter and we'll be sure to hook you up. People with immediate use cases and nonprofits tend to get early access relatively easily.