Things You Have To Know About the JAMStack & Why You Should Try It.
Nowadays we are seeing the term JAMStack everywhere, it is growing insanely and many sites are migrating to this architecture.
I am sure you are wondering about what makes it special ✨
Introduction:
Before we start talking about the JAMStack let’s take a look at how websites are delivered to the user. There are many approaches, so let’s talk about some of them! 😁
1• When we started building for the web we create assets, put them on a web server, somewhere, that they’d become available and then from the browser we ask for resources and we get it! Seems very simple, very straightforward, right ?
This approach was great and it stood up well for quite a while and that was efficient but we ran into limitations. The resources were static they weren’t able to be changed based on what people ask for so the experiences we were getting seemed static to be quite static as well.
2• In addition to the previous architecture, we tried to add something new to add some kind of level of dynamism at the server level. Now instead of just asking for stuff and getting it, the server would do stuff as well thanks to a script that would be executed for every request that would generate a view and the return it to the user.
That was great, we could respond to the needs of the user and create something dynamically and return it. It did mean that the responsibilities of the server now are quite different, we needed to make sure that for every request that came in we had enough capacity to service and get something back to the user quickly.
3• We started to introduce different bits of infrastructure so rather than just having a single web server that was creating those views, we started to add many web servers to handle the traffic and we’d perhaps put something in front of those web servers like a load balancer that dispatch each request to a specific web server, it shares the load accross web servers. We started to do more things like abstract where the data lived rather than the data being on a single web server and we abdicate the responsability and share some of the load with servers that are specific to that and abstract those out as well.
We got to a point that a request from the user for a page will travel through all of these different in bits of infrastruture gradually assembling a view that would get returned to the user into the browser rather than having something ready to go
4• We also started to think about maybe we could find some assets that are kind of static and don’t need generating on the fly and maybe we could put those in a different location. So we started to introduce things like a CDN (Content Delivery Network), networks give the machines geographically arranged so that wherever the user arrives from, some of the assets can be served directly from there whereas others would have to go and go through the previous architecture and get built up over time.
It got complicated, we got more sophisticated in that kind of things we were building and our inftrastructure got more complicated as a result.
⇒ Luckily though, we’ve been learning and building new tools se we don’t have to stay in the same picture that we’ve had for such a long time, we understand that the needs of users have changed and what we expect to build has changed but so as the tooling that allows us to get there.
A few things have changed, browser have gotten more capable, the web browser that you’ll be viewing this site in now is very different to the one we were using at the beginning when eveything was a little bit simpler, now browsers are a way more powerful, way more capable than they ever used to be and we can use those to great effect.
What is JAMStack ? 🤔
Before this “looooong” introduction, this question could be divided into two parts What JAMStack stands for ? and What does JAMStack mean ?
JAMStack stands for Javascript, API and Markup Stack, the term was officially coined in 2016, but the architecture have been around well before that and it’s the way to deliver fast and secure sites and applications delivered by pre-rendering files and serving them directly a CDN removing the requirement to manage or run web servers.
You might think there are a lot of stacks already of building things for the web with different technologies, like LAMP, XAMP, WISA, MEAN, MERN…etc
Take a look at the JAMStack architecture!
We have the actual web server that will do things like the HTTP routing and serving assets.
The runtime, the processing layer in effect the operating system, lives within the browser so we are not having to reach all the way down into an operating system like many stacks (LAMP…), that’s provided to us by the client that’s the runtime exists in the browser.
APIs, data access, we’ve kind of abstracted that away that’s kind of not part of our domain now. There’re APIs that exist out of the ecosystem that we can make use of, which we don’t have to manage ourselves. We can request access to those via their APIs and we typically do that using Javascript, so that’s why we get this kind of Trinity of markup delivering content and then if needed we can start to use Javascript in the browser to talk to the APIs and get content to embellish and enhance the experience in the browser.
So JAMStack is about:
• having things that are pre-rendred,
• leveraging the browser, its power and the technologies available to us in it,
• operating without a web server.
All of these things bring us to a bunch of different advantages:
🚀 Deployment:
If you are a front-end developer, i’m sure that one of your more painful parts of building a web applications is deploying a website. Using your favorite FTP client to manually managing files and stuff.
In the JAMStack world, there’re many tools like Netlify, AWS S3 and CloudFlare have given us the ability to automate DevOps. After connecting our project to either of the mentioned services with our Git provider, our website or application is automatically deployed any time changes are merged into the main branch.
🔒 Security:
In terms of security and how the JAMStack improve our outlook for security for websites, as you can see from this diagram, we’ve greatly reduced surface area when working with JAMStack compared to the other approaches.
The more infrastructure, moving part and code we have, the more we have to secure. Simply in the JAMStack there’re fewer moving parts in the scenario.
There is no server more secure than the one that doesn’t exist.
🤖 Performance:
When we think about how we’ve tried to improve performance in our traditional stack (the one on the last diagram) we’ve started to add some static layers to that, here we are talking about caching. In these diagram, each level of the stack, in order to try to speed up the process of the request, we’ve tried to minimize the dynamic things by saving the commonly requested templates and data so it’s ready to go when a request comes into it.
Compared to the JAMStack, everytime we do a deployment into our CDN effectively we are updating the entire serving cache, there is no logic that we have to manage this kind of barrier between what is cached and what needs to be dynamic.
📈 Scalability:
In the traditional stack, in order to scale we add more and more infrastructure, more bandwidth, more servers and more capability to handle the increased load, means more cost and complexity.
Compared to the JAMStack, things are different, by design and by default where everything is already cached there’s no additional dynamic work to do.
So we’re at an optimal position already, serving everything from a content delivery network which is from it’s very inception was designed to handle things at high load.
Every technology or architecture has pros and cons, the JAMStack offers many benefits that range from performance to cost-effectiveness, all while making developers happy with a better suite of tools to build with, but it does come with some concerns.
Thanks for reading. I hope this was helpful. If you have any questions, feel free to leave a response.
