JAMStack is a modern web development practice; the acronym JAM refers to client-side J avaScript, reusable A PIs, and prebuilt M arkup. In this article, we will explore what JAMStack is all about and the motivation behind it. In fact, I built my blog using JAMStack. If you're interested in setting one up for yourself, stick around. There will be tutorials in the upcoming posts to walk you through the process.

In this article, we will learn:

• What JAMStack is
• Components of the JAMStack architecture
• Available tools used to build a JAMStack app
• Benefits and limitations of JAMStack architecture

What is JAMStack?

JAMStack is an architecture designed to make the web faster, more secure, and easier to scale. _ How does JAMStack accomplish these goals? _ It's delivering these improvements via two core principles: _ pre-rendering _ and _ decoupling _.

• Pre-rendering : The entire front end is prebuilt into highly optimized static pages and assets during a _ build _ process using Static Site Generator (SSG) such as _ Gatsby, Hugo, Jekyll, Next.js , _etc.. The pre-rendered sites are then deployed and served directly from a Content Delivery Network (CDN), reducing the cost, complexity, and risk of dynamic servers.
• Decoupling : Unlike a traditional or _ "coupled" _ architecture (where the backend is deeply integrated into the frontend), the front and back ends are completely separated in the JAMStack architecture. Therefore, JAMStack is also known for its headless Content Management System (CMS). The term _ headless _ comes from the uncoupling of the "head" (the frontend) and the body (the backend). A _ headless CMS _ gives editors an interface for managing content, then provides that content over APIs for developers to build websites and apps with. Therefore, the CMS can focus on creating rich, powerful content authoring and editorial management workflows, without being weighed down or overly complicated because they're tied into presentation concerns.

Components of JAMStack

Let's dig into the "JAM", shall we? 😜

As mentioned above, JAMStack comprises of three components: JavaScript, API , and Markup.

1. JavaScript The component that's probably done the most work to popularize the JAMStack is JavaScript. Our browser language allows us to provide all of the dynamic and interactive bits that we might not have if we're serving plain HTML without it. UI Frameworks like React, Vue , and Svelte make building apps simpler and more organized by providing component APIs and tooling that compile down to simple HTML files. These HTML files include a group of asets like images, CSS, and the actual JavaScript that ultimately get served to a browser via your favorite CDN.
2. API Utilizing the strengths of API is core to how you make a JAMStack app dynamic. Whether it's authentication or search, your application will use JavaScript to make an HTTP request to another provider which will ultimately enhance the experience in one form or another. For example, you could have a headless CMS Ghost API where you store your content, a Cloudinary account where you store your images and videos, and an Elastic Search instance that provides your search functionality. They all work together to provide a single experience to the people using your site.
3. Markup Whether it's your hand-written HTML or the code that compiles down to the HTML, this is the critical piece since it's the first part you're serving to the client. To be considered a JAMStack app, the HTML needs to be served statically, i.e. not being dynamically rendered from a server. However, this doesn't mean that we have to build 100% of the app within the browser. Static Site Generators (SSG) allow us to pull in some or all of our API resources at build time and render the page out as HTML files. For example, using SSG, we can call the API to pull in all of our posts and create a new HTML file for each of those posts at build time. That way, we can serve a precompiled version of the page directly to the browser without having to interact with the API in the backend. Nice huh! 😎

How to build a JAMStack app?

1. Development However you decide to generate your HTML assets is up to you. The three most common approaches are:
   • Hand coding.
   • Static Site Generator: Most JAMStack sites are powered by a static site generator such as Gatsby, Next.js, Hugo , etc.
   • Site Builders: Tools that bring JAMStack to less technical users, while enabling developers to customize sites through modern tooling ( Stackbit, Builder.io, CloudCannon , etc.).
2. Dynamic Parts JAMStack sites don't have to be static. There are great services available to help bring some dynamic data to your product.
   • Custom functions: You can abstract your own functions into reusable APIs using AWS Lambda, Netlify Functions.
   • Custom data: As you add features to your site, you may want to store blog posts, user profiles, shopping cart data, game levels, or other dynamic data. There are many Database as a Service (DBaaS) tools available such as Fauna, Hasura, MongoDB Atlas, AWS DynamoDB , etc.
   • Comments: Many JAMStack products have dynamic comment sections that are typicaly used for blogs such as Staticman, Disqus.
   • Forms: Tools like Netlify Forms, Getform, FormKeep can be implemented.
   • E-Commerce: Available tools are Shopify, Snipcart, Commerce Layer.
   • Search: Third part services such as Algolia, fuse.js, Lunr.js can be integrated for search functionality.
3. CMS JAMStack sites can be controlled via a Content Management System , typically known as headless CMS. Once a change is made in the CMS, a new build of your site will be triggered and then deployed as static assets. Common CMSs are Netlify CMS, Contentful, Ghost, Strapi, Sanity.io, etc.
4. Deployment You'll likely need to set up an automatic build process (CI/CD), and your built site needs to be hosted somewhere. There are great services provided for free and with ease such as Netlify, Vercel, Digital Ocean, Azure Static Web Apps, etc.

Benefits of using JAMStack

• Speed: JAMStack sites load fast because of the way pages are built and deployed. JAMStack pages aren't generated via requests to a server, but are prebuilt and served over a CDN. Traditional server-built sites can utilize CDNs too, but only to store cached static content, like images and stylesheets. It's much faster when the entire site can be served via CDN. I have another blog hosted on WordPress, and I can tell you that there is a significant difference in speed between WordPress and JAMStack.
• Cost: Hosting static files is cheap, and is often free for smaller sites.
• Scalability: Scaling is much easier too. With a traditional site, spikes in traffic can be problematic because they can slow down the server, or even causes it to crash. With a CDN, it's easier to scale up to meet user demand.
• Developer Experience: Developers can pick any JavaScript libraries and frameworks (React, Vue, etc.) that they want to work with and leverage modern tools like Babel and Webpack. Also, there are a number of static site generators that makes setting up a great development environment incredibly easy. It's also convenient that the site's code is stored in a repository like Git instead of a server. When changes are made, the repository keeps track of the changes, and makes it possible to revert to previous versions.
• Security: Since JAMStack sites send out pre-built pages and don't have dynamic interactions with a server, they are far less prone to attacks. You don't have to worry about server or database vulnerabilities. WordPress sites require frequent updates to stay ahead of security vulnerabilities. Without attention to this, a site is open to malicious attacks.

Limitations of JAMStack

• Reliance on a developer: You have to know your way around JavaScript in order to get a JAMStack site running. A JAMStack site will be far more time consuming to set up than a WordPress site. With WordPress, anyone without technical knowledge can have a professional, functional website up and running in a short amount of time by simply installing the right plugins and theme.
• More static than dynamic: JAMStack is not a good option for highly dynamic sites such as sites that need constant updates (like a large news site) or ones that have lots of user interaction. One of the reasons for this is build time. When a change is made to the code or content of a site, a rebuild is triggered. If a site is large, it could take a long time to build, which can be annoying when making small updates or corrections. Static hosting services typically charge based on build minutes, so making frequent updates will quickly use up minutes unless you have a generous plan.

That's it for this week. In the next article of this series, we will compare JAMStack with WordPress to understand more of what problems JAMStack was created to solve. See you then! 👋