If you are fan of JavaScript then you no doubt have encountered the term JAMStack at some point in your career. In this post I'm going to break down what it is, how to use it, and whether it is as amazing as some websites make it out to be. Because, kind of. But not always. Before anything, let's start with a formal definition of what exactly the JAMStack is.
What is the JAMstack?
"JAM" refers to 3 specific technologies that together form a tech stack for web developers. What is a tech stack? It is the combined utilities needed to program in a certain language. The PHP LAMP stack for example would consist of the following:
- Linux
- Apache
- MySql
- PHP
The 3 components that make up a JAM website are as follows:
- JavaScript
- API's
- Markup
And that's pretty much it. There are no back-end servers to maintain or databases to connect to in this particular stack. At least, not directly. Note also that these aren't any specific technologies as they can refer to any number of things. API's can be custom built or leveraging 3rd parties. Markup can be generated in any number of ways as well, such as with React or Angular or the good old fashion hand coded HTML page with templates.
The primary focus of the JAMStack is its emphasis of being "serverless", which we'll go into down below. But first, a few benefits.
What are some of the benefits?
There are a few benefits to not having to deal with servers, back-end code and databases. And a few drawbacks as well, which I will go into further down below. But for now, a few benefits are:
- Faster page load times
- Cheaper and simpler scaling
- Potentially more secure
- Looser coupling of code
Let's dive a bit deeper into each one of these.
Faster page load times - With most server-side rendered web applications, the client (browser) has to wait for the HTTP resources to be generated on the server before being rendered on the client. And depending on the operations being performed in the background, the milliseconds could definitely add up.
On average, any server-side web page typically has to read data from a datastore, embed this data onto the page, perform security checks and validations and perform any custom operations as well. And these things also depend on the performance of the server that they are hosted on.
But because the JAMStack relies on client-side API integrations, pages are pretty much served immediately to the users, as the Markup is already pre-formatted. And because there are no backend server dependencies, this also means that you can spread your markup across the board using CDN's.
Cheaper and simpler scaling - Because there are no real server pages to render in this stack, files aren't married to any eco-system. By that I mean that they are free to be stored on any server from any provider in any OS.
Alternatively, if you were a PHP developer for example, you would need to host your application on an Apache web server preferably running some flavor of Linux.
This means that you can publish once and have your code updated across many different servers closest to your site visitors.
Potentially more secure - The idea behind increased security here being that because your data is retrieved from API's, the point of attack is reduced. Most in-house applications normally house code, resources and data under the same server. The potential for data-loss in these cases is much more elevated.
I say potentially more secure in this case, because the security aspect would be more in the hands of whichever party is hosting your API's. Whereas under certain conditions, a company might host its own data and make use of their own custom encryption methods when serving data to a page.
This would also depend on the overall security demands of the particular application as well, which I'll go into down below in the "not for everyone" section.
Looser coupling of code - Separation of concerns is always a plus when coding any application. In this case you are working with JavaScript files, data API's and markup files served through some CDN.
This loose coupling leads to smaller files to work on and opens up the potential for more parties to work on the code at once without interfering too much with each other.
Note that this would also depend on the specific implementation of your JAMStack.
How it works
Let's take a look at a very simple implementation of a JAMStack project. Starting off with the JavaScript portion.
"JavaScript"
function loadData()
{
$.ajax({
url: "/api/get/data",
context: document.body
}).done(function() {
});
}
Your JavaScript code would need to make use of the Ajax functionality in order to make requests to any API's that you are integrating with. This is essentially how you would retrieve any and all dynamic data that needs to be loaded on your app.
"API"
This will come down to your preferred method of retrieving data and implementing API's. While you can build your own custom API (outside the scope of this article) and serve your page content in that way, you can also leverage 3rd party API's to store and host your data.
"Markup"
<div>
<div>{{blog.title}}</div>
<div>{{blog.content}}</div>
</div>
Similar to the API scenario, your Markup can be generated using any templating engine that you wish. Anything from React to Angular, to your own custom templating style is valid here. You could even just load standard HTML pages and replace the various elements with their content on page load.
The point here being that the markup is completely independent from any type of server-side rendering engine. And that is essentially the makeup of a JAMStack project. Relatively simple and lightweight for sure. But...
Not for every app
While there are many benefits to implementing your apps in such a decoupled and loose way, it might not be applicable to every situation. If, for example, you are relying heavily on any server side language:
- C#
- PHP
- Java
Then having an added "stack" on top of another won't make things any easier for you as you would still require that particular languages eco-system.
Anytime that you are working with secure data, such as credit-card information, you will need to follow certain security protocols in order to be compliant. And many times, this comes down to various private-key encryption methods that you need to implement on the server as you don't want to expose private security keys in your client side code.
In these specific cases, it is best to avoid the added work involved in setting up a "Serverless + Server" architecture.
In a nutshell...
Note that the JAMStack isn't any one specific technology that you download, but a combination of already stable and robust methodologies that you combine to create very fast loading and secure web applications that can be scaled and served from almost anywhere using a CDN.
Comment down below if you are already using this stack in your own projects.
If you enjoyed this post, hit the like button below. And if enough people like it, there will be more JAMStack posts coming soon.
- Walt