Jamstack is an architecture designed to make the web faster, more secure, and easier to scale. The key to understanding JAMstack is knowing the difference between static and dynamic in the web world.
What’s the JAMstack all about?
The JAMstack has been getting a lot of buzz since it came into being, and there has been a lot of talk in web development communities as to whether or not you should move from WordPress to JAMstack. I thought I should write an overview article about this so that you can see if it is the right choice for your project.
The key to understanding JAMstack is knowing the difference between static and dynamic in the web world.
Simply put, static means that you have pre-built or pre-computed something and pre-compiled it on a static hosting system. Dynamic is where you are actually building something on the fly, computing it in response to every single request. When you think about it intuitively, it is going to be a lot faster and a lot cheaper to respond with something you already have, as opposed to computing something on the fly in response to every single request.
An old-school web server has three primary jobs: Serve HTML, static assets, and API endpoints. Nowadays, all your static assets are going to be on something like Amazon’s S3. When it comes to APIs, we have already moved those onto other servers or a set of servers if you are doing the micro-services thing.
This leaves the web server doing just one job, and that is serving HTML pages. If that is so, can we make those pages static? For that, we need to understand how a web server renders an HTML page.
Say a visitor goes to Medium’s home page. The request goes to the server, which connects to the API, asks for the data on the page, formats the HTML response, and then sends it back to the visitor fully rendered.
There is yet another new way of doing the same thing. During build time, in response to data or code changes, a server goes and gets a list of all the data from the database and then uses a set of templates to format a site that has all of that in it. All of those pages are completely pre-rendered and go up on something like Amazon’s S3. When the visitor goes to that page, they immediately get back a page that is completely rendered.
The beauty of this is that you only have to render that data once into HTML. In the other models (client-side and server-side rendering), you render that HTML every single time, regardless of where it is being done. A key element is that every customer is going to get the same HTML page for a given URL. In two of these models (client-side rendering and static site generation), we can get rid of that web server and save ourselves a whole lot of time and money, which is usually everyone’s goal.
This is what JAMstack is all about.
APIs can be as simple as 1 endpoint for use by 100s of users or as complex as the AWS APIs with 1000s of endpoints and 100s of thousands of users. Building them can mean spending a couple of hours using a low-code platform or months of work using a multitude of tools. Hosting them can be as simple as using one platform that does everything we need or as complex as setting up and managing ingress control, security, caching, failover, metrics, scaling.
Measuring website activity provides only half the story. See how to best track the developer's journey and what funnel stages makes sense for API-first products
Selling to developers is hard. How to market to developers efficiently using paid advertising leveraging inbound marketing techniques.
APIs are perceived as reliable—more than half of respondents stated that APIs do not break, stop working, or materially change specification often enough to matter.
In today’s world of ever-increasing digital interconnectivity, APIs have emerged as essential tools for integrating data efficiently and cost-effectively. In this article we'll talk about the following five main factors behind the remarkable evolution of APIs in recent years