A look at the pros—and cons—of the JAMstack
The world of web development has many different moving parts and concepts that emerge over time as organizations seek to achieve an engaging, state-of-the-art digital experience. Over the past few years, one such trend has increasingly come to the fore—the JAMstack.
But what is JAMstack, and why is everyone talking about it? The concept is relatively recent—in 2015, static websites were growing in popularity thanks in part to site generators like Jekyll. Given the rise in popularity, some developers began seeing an opportunity to improve their web development experience, and the term JAMstack became more widely adopted in 2017.
What is JAMstack?
And it’s an attractive idea when considering the request cycle of a dynamic site: a user makes a request on a front end that goes to the server, then to the database, where queries are made, and then HTML is output to the user. This happens each time a user makes a request. The potential downsides of this cycle include:
- Speed: A longer request cycle takes more time
- Scalability: Too many requests can overload the server
- Security: The database is still a part of the equation
The pros of JAMstack
JAMstack, on the other hand, switches this up by offering pre-built, templated markup. Instead of following the path back to the database and serving up HTML to the user each time a request is made, the user is instead rapidly served a static page.
On that static page, APIs can dynamically retrieve other data that requires constant refreshing or updating, like user profiles, commenting, or real-time information like stock tickers or news feeds. In case of an outage, only the content produced by the service that is down would be unavailable (but assuming the static content is served by a reliable CDN, it will virtually always be available).
JAMStack then answers the shortcomings of a dynamic site:
- Speed: JAMstack can be faster since everything is being served on a client-side server
- Scalability: JAMstack can be more scalable since static requests respond immediately and thus are not as liable to be bogged down
- Security: JAMstack can be more secure since requests are not hitting the database
Though the JAMstack is appropriately regarded as being a new and—for some—beneficial concept in the world of web development, it is not a magic bullet; it does come with some concerns that organizations will need to weigh when making their considerations.
The cons of JAMstack
Because JAMstack websites are characterized by a static front end, there is no need for requests to be made to a database on the back end. While this is attractive from a security standpoint, it does also mean that any changes that need to be made to a front end must be made manually, and per website, since site visitors are all displayed the same content.
On a larger scale, this may mean that developers are forced to run scripts non-stop to keep content updated on the server. It may require a code change to do something like restructuring the layout of a page.
Additionally, while the JAMstack does remove the database from the equation in this regard, there are still potential security vulnerabilities with the front end you choose. Your fate is in the hands of the front end should ever there be a breach.
How Brightspot can help
The Brightspot CMS is a highly extensible and front-end agnostic solution that was built to fit any scenario you can throw at it. Through integration-ready and publisher-informed technology, Brightspot can easily serve as the "A" in JAMstack if, for example, an organization is using a front end like React or Node.js that is hosted in S3 on a static Apache or NGINX server, with Brightspot (and our GraphQL APIs) delivering the dynamic content.
In a typical Brightspot implementation, there is sophisticated business logic and many integrations on the back end to which front ends simply will simply not have access, like users in the system or personalization; however, in a JAMstack scenario, we can bring all of these elements together. Brightspot can consolidate all of the various services, business logic, dynamic and static content, personalization, and more thanks to our multi-channel delivery paradigm. This content can be delivered via GraphQL, XML, JSON, HTML, HTML fragments, or any other format.
And there is additional value to enjoy should you want to rely more on Brightspot's powerful back end, like intuitive data modeling and robust workflow capabilities that enable both content creators and developers to solve the problems they face. Flexibility is the name of the game, and organizations that use Brightspot have it in spades, free to choose the exact approach that works best for their unique business needs.
With many JAMstack implementations, the real dynamic behavior of the site is owned by the programmer, and only that programmer. This is one of the reasons why JAMstack is so attractive to web developers; however, in these scenarios, the programmer is not enabling the publisher to make that happen.
Brightspot, on the other hand, enables publishers to have the type of power that traditionally only developers have.