JAMStack vs serverless web apps
JAMStack seems to be one of the most trending topics right now. So are serverless web apps. Hot and loved! I’ve seen some tweets, articles and even live presentations just this week that talk about JAMStack and serverless web apps as if they are the same. For good reason. In an ideal scenario, serverless web apps and JAMStack sites/apps are indistinguishable.
But, it’s in the details where both differ. Let’s dig deeper.
JAMStack sites/apps #
Let’s focus on the “M” in JAMStack. Statically generated markup. Generated by a static site generator. Probably the one thing that tends to be overlooked when talking about JAMStack vs. serverless web apps.
As soon as we deploy and serve statically generated markup, our sites qualify for being a JAMStack site.
This is progressive enhancement in its purest form. That’s why so many people love it.
What about APIs, though? In an ideal scenario, the only APIs we call are serverless or cloud functions. Because they are cheap. They allow for self-healing. They scale. They might have a lower security attack surface.
Best case: Serverless. A bunch of URLs: Good enough.
Serverless web apps #
If we serve actual content, the HTML does not have to be statically stored or pre-generated. It can be generated dynamically through server-side rendering.
The best case scenario? Just like JAMStack: We have our content pre-generated and served statically. Maybe via a CDN to have the cheapest and most effective delivery secured.
Bottom line #
In JAMStack apps, the “A” can be any API to call. Preferably serverless. The “M” though, is statically generated markup. Serverless web apps are much stricter on the “A” part. Markup though is a whole different story.
If you care about performance, security, discoverability and resilience, I recommend architecting both serverless web apps and JAMStack sites the same.