Configuration is often more work than it’s worth. As frontend developers, focused on the front end, configuring builds adds an extra layer of cognitive burden and can take away from completing the primary task at hand. The JAMstack seeks to abstract configuration in favor of a more streamlined workflow where complexity can be built in piecemeal or even outsourced entirely to a separate microservice. Building in this manner can cause unneeded complexity in applications in a more conscientious fashion and enables them to better reason about logic in their applications.
To highlight what makes the JAMstack so easily configurable compared to other frameworks for building sites, we’ll examine a few key points: namely Build Automation, Event Triggers, APIs and Serverless Functions.
Build automation is a key component of what makes the JAMstack architecture so compelling. Many JAMstack setups make use of modern Static Site Generators like Hugo and 11ty and Frontend frameworks like React and Vue to speed up development. These frameworks not only help scaffold a project, they also provide the necessary tools to create production ready code. Deployment platforms like Netlify further streamline this workflow by automating the build and deploy process so code can be shipped with little to no opportunity for error. To learn more about what’s possible with build automation, check out this post where Phil Hawksworth walks you through how he built an auto-updating clock with Netlify
With an automated workflow, comes the ability to hook into events as they happen like whether a deploy failed or succeeded. This event-driven architecture is made possible with webhooks, which are simple ways to connect events and services that otherwise have no knowledge of one another. IFTTT is an example of such an event triggered workflow where changes that occur within web services like Gmail, and Instagram can in turn trigger changes to other services.
An automated build process where updates to a Git repository sets off the build and deploy process, is another instance of webhooks in action. The popularity of this event-driven model has led to a rich, and fast growing ecosystem. Multiple web services now offer the ability to register their service as a webhook to get notified when events occur. This form of an event-driven model to automate tasks means static sites are a lot less “static” than we might once have expected. To learn more about how you can use webhooks to trigger new builds on Netlify, check out the Build hooks docs
In direct contrast to traditional monolithic set ups that have to prematurely optimize for scale, the JAMstack is designed to scale only when needed. It does this by shirking infrastructure that needs to be available at all times with one that only runs when needed. Serverless functions make this workflow possible by offering the ability to invoke functions only when necessary. This coupled with a static infrastructure means that sites can be served quickly without the extra latency of a full site rebuild. Moving away from servers has the added benefit of significantly reduced cost and energy since servers no longer need to be provisioned and kept alive prematurely. To learn more about serverless functions and how you can take advantage of them in your sites, check out this post I wrote about connecting your netlify forms to firebase via Netlify Functions
Toast to JAMstack
The formalization of the term JAMstack has brought with it a resurgence of static sites as an architecture for building fast and secure sites. Though complex, dynamic sites continue to be popular, the JAMstack’s promise of simplicity and abstraction is undeniably appealing. Since its introduction 5 years ago, the JAMstack ecosystem has grown rapidly and we’re beginning to see widespread adoption in the enterprise space. If you’re keen on learning more, be sure to check out these handy Static Site Starter templates to get started on creating your own JAMstack site. We look forward to see what you’ll build!