In the recent years there had been significant buzz about JAM stack, many people have adopted it and it has been a pleasant experience working towards a better web.
- JAM stack architecture usually consists of a static site generator.
- It is cost effective solution as there isn’t a need of a dedicated web server. Just pay for storage and for compute power used during build and deployments.
- As the Front-end is getting more complex nowadays, this helps in decoupling front-end from backend and server infrastructure.
- A stands for API which is responsible for connecting the data source to the user interface. It consists of all the server-side processes and database actions. This could be some Content Management System (CMS).
- M stands for Markup that is the html template generated at build time after pulling the required content from data souce by using APIs.
Mostly we use a static site generator when following the JAM stack architecture.
Static site generators are just some tools that takes in the content from data source and then generate HTML pages based on that content.
This gives us pre generated HTML files along with the content present in it. This is ideal for Search Engine Optimization (SEO) and for faster initial loading time.
- Better Performance by generating the pages at deploy time rather than building them on the fly on client side.
- Higher Security with our server side processes abstracted into microservices APIs, hence surface areas for attack are reduced.
- Easy to Scale using a CDN since we just have to serve a bunch of static files.
We should avoid JAM stack whenever-
- We need a tight coupling between client and server.
- Our app uses isomorphic rendering to build views on server at runtime.
- Entire project on CDN.
- Everything lives in Git.
- Modern Build Tools.
- Automated Builds.
- Atomic Deploys.
- Instant Cache Invalidation.
PS: This blog website of mine is also based on JAM stack.
- Ayush 🙂