JAMstack for All: An Introduction

Subscribe to my newsletter and never miss my upcoming articles

Welcome to the brand new series on JAMstack called, JAMstack for All. This is the first article from the series, and I would like to keep it as an Introduction to JAMstack.

Before we go on, let me first introduce the Series to all of you. As the name indicates, it is for all. No matter, if you are a Full-Stack, Client-only, Server-preferred, from Quality or DevOps teams.

This series will cover,

  • ✍️ An Introduction to JAMstack. That's all in this article.
  • ✍️ Traditional vs JAMstack.
  • ✍️ Technology Ecosystem around JAMstack.
  • ✍️ JAMstack for the Enterprise and Server side of the things.
  • ✍️ Where JAMstack may not fit well.
  • ✍️ Case studies, Workflows, Examples, and lots of resources to learn ahead.

The primary objective of this series is to share my working knowledge on JAMstack with you so that, you as a reader can gain knowledge out of it. So let us get started.

A bit of History

Once upon a time(yeah, it sounds like those fairy tales), web content used to be static. There were only a few content creators while the majority were consumers. There were no options for the users(or consumers) to contribute the content back.

These contents used to be served from the server’s file-system and the pages were built using Server Side Includes(SSI) or Common Gateway Interface (CGI). This era of the web was famously known as Web 1.0.


As time passed, consumers built the interest to contribute. The demand to interact and collaborate through social media grown bigger. The desire of sharing user-generated content gave birth to many virtual communities.

With this demand and desire, static pages served from a server was not enough. There was an increasing need for better markup support, page style support, and some sort of dynamic content. The likes of HTML, CSS, and JavaScript were introduced to content creators and application developers.

The Client-Server architecture also evolved where a database or storage was needed to store the content, A server to serve it on demand, and finally, the Client to request it. Enterprise application solutions also started becoming more user friendly and at the same time, more complex to manage. This era of the web is called, web 2.0. We all are proudly part of it today to a great extent.

Here is a very high-level diagram of how a monolithic client-server architecture model may look like, Web2.png

Few important aspects to note here. Each of the blocks shown above may need some plumbings overtimes. Be it for upgrading OS versions, security patching, end-of-life of the services, or any other miscellaneous maintenance.

The database may need an add-on based on the customer use-cases, the web and application servers may need plug-ins based on the situations. But, the bigger question to ask,

Who will do all these plumbings/patching/maintenances?


The answer is very simple. However, the work of upgrading, security patching, and maintaining are not so trivial. For example,

  • If you have your website built, managed, and hosted with blog creation tools like WordPress(or WordPress CMS), Drupal etc, it is their responsibility to make sure, all maintenance, security fixes, OS upgrade, etc happen on time.

    Is WordPress secured? Well, it depends. But, as a user. you are locked with these platforms even when a security vulnerability is found or the origin server is down. You are directly impacted.

  • In the case of an enterprise application, all these have to be maintained by developers, testers, build experts. We can not afford any of the security issues, huge lags, downtime, etc to impact our customers.

    Don't forget about the cost. Managing, maintaining servers, databases in-house are not cost-friendly. It has to be funded well by the respective business units as part of its budget plans.

No matter what, these three pillars are extremely important to consider for a blogging platform, content creator, or an enterprise app. Your users and customers are based on these three pillars of success. image.png


Alright, finally we are here. It was the year 2016 when few developers came together to promote the JAMstack principles but, the boom started in the year 2017 when the JAMstack concept was pushed further. The community started growing around it. The last three years have been extremely well for JAMstack with people taking it more seriously than ever.

So, what is JAMstack?

"A modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup" — Mathias Biilmann (CEO & Co-founder of Netlify).

The JAM of JAMstack stands for, Jamven.png

A technology stack is not a new thing. We have seen many stacks evolved in the last couple of decades. An important point to note here is, unlike many of the technology stacks in past, JAMstack is not yet another technology stack. It is rather an architectural concept. The fundamentals of this stack are based on, JavaScript, API, and Markup.

The image below shows the conceptual differences between JAMstack and other technology stacks like LAMP, MEAN, and MERN. Stack.png

JAMstack Myths

As a beginner to the JAMstack, you may be learning a few things which are eventually myths(or misguided information). Here are a few that I have heard initially and was proven wrong as I gained more knowledge about this,

  • JAMstack is only for static apps(pages).
  • JAMstack is only for Websites.
  • An Enterprise app will not scale with it.
  • It is reactJs based.
  • GitOps is a new thing.
  • Huge Learning curve required.
  • JAMstack can reduce Jobs!

Well, none of the above are true. We will prove it as we go further in this series. Please stay tuned.

Prerequisites and Mindset

JavaScript, API, and Markup are the bases of JAMstack. However, there are other three important keywords to keep in mind,

  • Client-Side JavaScript
  • Re-usable API
  • Pre-built Mark-up

We will need to call out a few prerequisites and demand a fresh mindset to implement a JAMstack solution. Do not worry if some of these are new to you. We are going to get into the depth of these in the future articles of this series.

  • Entire App is on CDN(or ADN). CDN stands for Content Delivery Network and ADN is Application Delivery Network.
  • Everything lives in GIT.
  • Automated builds with a workflow when developers push the code.
  • Automatic deploy of the pre-built markup to the CDN/ADN.
  • Practically Server Less(with terms and conditions).


So what are the benefits of doing all these? Remember those three pillars we spoke about in the beginning? Security, Cost, and Speed? Yes, that's the benefit we will be reaping here,

  • "Practically Serverless" removes lots of points of failures & security exploits.
  • The pre-built content served via CDN provides extra speedy user experiences.
  • The lesser complexity of development reduces costs.
  • Develop => Build => Test => Deploy Cycle is very well managed.

What's next

I get that, it was all of theories and fundamentals. Yes, that was purely intentional. This article is about the JAMstack introduction and, none of the new is so enjoyable without knowing the history, what, and why part of it. Thank you for reading through. Really appreciate.

In the future articles of the series, we will do a deep dive into the differences between a Traditional monolithic app and a JAMstack application. We will start looking into the usage of Static Site Generators(SSG) like Gatsby, Next, Hugo, etc. We will start seeing why Headless CMS like Netlify CMS, Strapi, etc are important to be aware of. How about the practical examples of the CDNs like Nelify, CloudFront etc?

That's all for now. See you with the next one soon ⏱️.

If it was useful to you, please Like/Share so that, it reaches others as well. To get e-mail notification on my latest posts, please subscribe to my blog by hitting the Subscribe button at the top of the page. You can also follow me on twitter @tapasadhikary.

Michael Fasani's photo

Tapas, this was great! I look forward to the next piece in the series.

I just started with Gatsby+AWS recently and I’m really enjoying learning from people who have been doing it longer, many web applications today could benefit from being mostly static (I think).

I have three questions for you: 🥳

Have you tried many SSG’s, what’s your personal favorite?🤔

As CI/CD is an important part of the process, How important is it to host with a large company like AWS, having access to those technologies, routing, CDN, serverless functions, do you think that’s important for the JAM stack?🤨

I have only tried AWS but I plan to investigate Netlify, do you recommend any others?🧐

I worry as a business evolves, the need for compute power potentially arises and then I’m not sure about the JAM stack, but that’s why I look forward to the next articles and hearing more. 😀

Tapas Adhikary's photo

Michael Fasani,

First of all, great to have a reader like you! Really appreciate that, you took time to read, showed interest in the series and asked valuable questions 👍 🙏.

Let me try answering those:

Have you tried many SSG’s, what’s your personal favorite?

😃 I have not tried many. I have tried just three so far. Gatsby, Next and Hugo. I have called them out in my favorite order, however I liked all of them. As I am planning an article to touch-base the SSGs, I would save my answer until then on why Gatsby is my favorite(until now, with little bit of frustrations).

As CI/CD is an important part of the process, How important is it to host with a large company like AWS, having access to those technologies, routing, CDN, serverless functions, do you think that’s important for the JAM stack?

💡 One of the characteristics of JAMstack is Automatic Build and Automatic Deploy. No doubt, it has to be continuous too. I think it is important(cost, speed and security wise) to bank on some of those like AWS(Though I am not recommending only AWS here!). For my organization case, things are on AWS. Many of my personal projects on Netlify and GCP.

I have only tried AWS but I plan to investigate Netlify, do you recommend any others?

🔥 Yes I do. However we need to be clear on-the use-cases. Netlify can not replace AWS usage completely today but, there are many uses-cases for them to co-exist for a single solution. One example is, Netlify Functions which are easy deployment of AWS Lambda functions. With that, you may not want to use AWS cloudfront and have the JAM deployed with Netlify. I will be covering this part in one of the articles in the series when we see the server side of the things.

I worry as a business evolves, the need for compute power potentially arises and then I’m not sure about the JAM stack, but that’s why I look forward to the next articles and hearing more.

✍️ I will go back to my three pillar concept again. Security, Cost and Speed. The computing power and cost of managing those also related some ways. Yes, I am surely going to write about it in depth in future articles of the series.

💡 Thank you very much for asking and it also guide me further to design future articles of the series.

Have a great day!

Bolaji Ayodeji's photo

This is really great Tapas, thanks for sharing!

Koustov's photo

Its nice read. Great content Tapas Adhikary. Looking forwards for more of these kind of writeups.

Wachukwu Emmanuel's photo

This is a very nice article Tapas! I like the way you broke down the acronyms.

Tapas Adhikary's photo

Thank you very much!


been wanting to get an insight on JAMstack, can't wait for the coming parts, cheers.

Tapas Adhikary's photo

Thanks NELSON MICHAEL! Cool, coming parts are on the way 😃.

Diana Chin's photo

This is fantastic! I've started working with JAMstack earlier this year and it's great to see some more insight about it.

Obi Zim's photo

Thanks for this article. Haven't understand fully the JAMstack concept but I await this series.

Tapas Adhikary's photo

Sure Obi Zim, will try my best!

Victoria Lo's photo

Always a delight to read your articles! Looking forward to the series :)