APIs: Any external data required to render a page is returned from an API. It does not matter if the API is a third-party SAAS service, or a serverless function. All data access is done with AJAX. No server-side code is used in a JAMStack website.
Markup: Web pages that are served as static HTML pages.
As you can see there is nothing new here. In fact, creating a website based on static HTML alone sounds like something out of the 90's! What then makes a JAMStack architecture cool? To understand this coolness, let us first consider the pitfalls of how most current CMS based websites are built.
🌐 Traditional CMS Architecture
Below shows how a typical web request is made to a CMS configured in a traditional architecture:
Traditionally the CMS server is the most important part of your web architecture, it is also the most fragile! When the CMS is the key part of your architecture there are four big failing points, bugs, time, added complexity and cost:
- *Bugs: * A web request comes in, the server processes stuff, then a page is returned. The biggest issue with this architecture is that if the server has an issue, the site is down. If the code has a bug, a request to a webpage might not work.
- *Time: * Another consideration is time. When a request to the server is made a lot of time is wasted. It takes time for a server to call the underlining code. It then takes time for the code to call the CMS. The CMS takes time when talking to the database. Do not forget, it takes time to build up the page HTML and then return it back to the client. These delays combined impact page load time.
- *Complexity: * To make our pages load faster, we add caching. This means we need to write code to cache things. Caching strategies can be tricky and complex to get right. Caching bugs can cause no end of bugs! We will also likely need a CDN to host our cached resources.
- *Cost: * As the CMS server is vital and it needs to process lots of things quickly, we need to throw a lot of processing power at it This means our infrastructure costs us more to run.
🌐 JamStack Architecture
Let us compare things to a JAMStack architecture. In a JAMStack architecture this central CMS server is no longer the most vital part of the puzzle:
Let us consider why this architecture is good, what are the benefits of using JAMStack?
* Faster performance: * Serving pre-built static HTML pages over an edge network is really quick. You can not get much quicker than an HTML page!
* More secure: * No need to worry about server or database vulnerabilities. As the website is HTML based you do not need to worry about injection attacks anymore!
* Less expensive: * Hosting of static files are cheaper. The CMS server does not need to be as powerful as it is only used by content editors.
Static Site Generation
As the site is dynamic, your code can talk to backend APIs using AJAX when any additional data is required. The APIs can do the complex and heavy lifting. These APIs can even use a mix of languages, they can be written in Node, C#, or even GO. We are no longer limited to using the central CMS server that used to restrict us on how we create things. Normally it made sense to build the backend APIs using the same technology as the CMS was written in. This is no longer the case. It now makes more sense to use the best of breed in technology to build your APIs. Building small micro-services using the most appropriate programming language and technology to suit its needs. This is great!
The next term you will often hear in JAMStack circles is the edge network. Edge networks are a fancy word for a CDN with a few fancy features. Netlify is the leading provider for JAMStack hosting. This is not an ad for Netlify, however, it is free to try out and they allow you to host your sites for free. I host 20-30 of my demo sites on Netlify and I can personally recommend it as an easy to use hosting option.
When the code is pushed into Netlify, the static files are copied across the world using its edge network the same way a CDN would work. The nice part about all of this is that you no longer need to worry about having to add the cache headers yourself.
Another great part of having static files for a release is 'atomic deploys'. Each release build is a full snapshot of the site at a point in time. Having all the files and content required for a deployment contained within an individual bundled release makes release management super simple. Want to roll back your site? Simply change the folder the production site is pointing at. These types of releases are super quick, taking only a few seconds. If you spot an issue in production you no longer have to rebuild code, wait for the server to spin up, pre-warm your site up. As everything is static HTML, you simply re-point production to a different build bundle and the site switch is done instantly. This is another amazing feature of the JAMStack! The great things about these bundles is that they are created automatically for you... how?
JAMStack architectures relies on webhooks. The webhook is the mechanism that triggers these atomic deploys whenever a content editor publishes content within the CMS. In JAMStack you will use webhooks often to make sure that different SAAS providers, CMS providers and hosting providers communicate with each other. All the JAMStack providers that I have worked with are all webhook enabled. This leads us to the final reason why JAMStack architectures are cool. Unfortunately, I will need to use a yukky buzz-word, however, with webhooks, we can fully adopt best of breed technologies (sorry!)
NOTE: If you do not want content editors automatically pushing content to production you can disable this feature. The point is that through webhooks we can get different systems to play nicely together easily.
Best Of Breed
You will hear a lot of technology directors and product partners bang on about “Best-of-breed technology” when researching JAMStack. Pretty much all headless CMS vendors will mention best of breed their websites numerous times. When you start researching best of breed, you will find literally hundreds of new SASS providers that you can use to build your websites now. Take a look at the diagram below, this sums up a few:
You will hear a lot of technology directors and product partners bang on about “Best-of-breed technology” when researching JAMStack. Pretty much all headless CMS vendors will mention best of breed on their websites and in any of their webinars numerous times. When you start researching the best of breed, you will find literally hundreds of new SASS providers that you can use to help power your website. Preventing you from having to write the same code over and over again from scratch. The diagram below highlights just a few of these companies. Trust me when I say there are many more!
Instead of writing custom solutions to common problems - which let us face it are usually a bit janky - it is much easier to call an established platforms API from your JAMStack site. This best of breed further quickens your development experience. Gone are the days of having to custom make everything. By using best of breed and JAMStack you can build websites in hours, not weeks. This is where the real power lies. Being able to do the same tasks quicker and cheaper. This is why JAMStack will continue to grow, it will make your life easier and it will save your company money. Why wouldn't you give it a go? Happy Coding 🤘