ETO: An Introduction to JAMstack (and API-Driven CMS)

p>Every once in a while, a new acronym, buzzword, or upstart concept starts to propagate in our industry. In this Executive Technology Overview (ETO) series, I’ll explain in layman’s terms what the most popular technology trends mean from a business perspective and give you guidance as to whether or not these solutions make sense for your organization.

The most recent buzzword in the CMS industry is a concept referred to as “JAMstack,” which stands loosely for JavaScript, APIs, and Markup. Originally coined by Mathias Biilmann, it is meant to describe a “modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.”

In layman’s terms, we can define the JAMstack as being a collection of tools and techniques wrapped around one common concept, which is that the client-side experience is removed from the back-end logic of typical programming languages instead powering user experiences by accessing data via APIs or programming interfaces. In most cases, this also includes statically-generating your website, or at least the majority of functionality.

The name “JAMstack” makes vague reference to the ubiquitous terminology in use today, “tech stack.” However, it’s important to know there is a plethora of differences between what the JAMstack is and what constitutes a traditional tech stack.

In industry normal parlance, tech stacks contain not just front-end experience enablement, but also back-end technology such as scripting languages, databases, and web servers. JAMstack experiences and projects still need these items—they just treat them as third parties of lesser concern.

To build a JAMstack experience, you’ll need an API that is ultimately powered by a tech stack accessing a database. In many cases, this will include some level of a CMS platform. JAMstack practitioners recognize this, yet they are less concerned about the specifics, leaving them to rely on “full stack” developers or outside parties (i.e. CMS providers). More on this later.

So, what does JAMstack mean for the average CMO, CEO, or other executive looking to make a technology decision?

Basically, it means you have another option versus the utilization of typical, monolithic solutions such as WordPress, Drupal, and the host of commercial options out there.

It also means that your decision-making process is now even more complex than it was before.

The History of JAMstack

In many ways, JAMstack is simply taking us backwards 20 years to the age of static websites. However, it’s allowing us to retain all the technology we’ve developed since then in terms of content management, interactivity, and user experience.

Back when I began my career in web development, managing a website meant managing thousands of HTML files that were all linked together. Today, almost every project utilizes a content management system, and most of these are coupled systems. This means that the back-end administrative layer is integrated into the same logic layer as the front-end, sharing much functionality. This “coupled” approach has been the mainstay of the content management industry for almost 20 years now, and is the architecture behind the most popular platforms available.

The introduction of coupled CMS technology brought with it, however, many concerns. From a security perspective, websites ceased to simply be groups of files, but rather became sophisticated applications that had thousands of dependencies. With the complexity came gaps, which nefarious characters have been quick to pounce on. Likewise, CMS platforms became slow, bogged down by entirely too much functionality, as each open-source project and vendor attempted to outshine the competition.

Most technically minded folks have been aware of these issues for years. However, due to the scale of the internet and the ability to spin off websites quickly with these applications, they became more and more prevalent anyway. Today, CMSs power almost every site you see, and most are still based on monolithic, coupled platforms.

As the internet grew, developers and businesses alike saw the power of integrations. With that came the advent of markup that allowed for data to be shared. Starting with XML and then progressing to JSON and other mediums, developers invented mechanisms to share data and functionality. And to streamline it all, the API generation was born.

In recent years, developers have taken the problems of the CMS world and addressed them with solutions that revolve around the API trend and the concept of portable data. With this, the era of the “headless” CMS was ushered in. Headless platforms take the CMS part of a platform—the content management—and break it into a separate utility. Developers can access data in the CMS via API connectivity.

But what methodology can you use to utilize that data?

Enter JAMstack. The usage of JavaScript, APIs and Markup. Combined, these tools can utilize data made accessible via API and display them in a creative, intuitive UI/UX, or “markup.”

Applications

So, what is the most common application of the JAMstack?

As I mentioned earlier, the concept applies to websites first and foremost. The most prevalent case studies include the following parts:

• CMS: The CMS component, while not being part of the overall JAMstack concept, is integral in making JAMstack projects actual, viable options for executives and content managers. Without a CMS, there is no content repository and the purpose of utilizing a concept such as JAMstack makes zero sense.
  
  In most cases, headless CMSs make the most sense. While monolithic players such as WordPress and Drupal have already jumped head-first into the API game, it’s important to remember that they are not natively created for this purpose; using those systems can be, in many cases, counterproductive. I won’t waste time discussing this in too much depth, but for the purposes of clean, future-proofed content, the utilization of true headless systems is recommended.
   
• Static Site Generator: Be still my heart—we’re going back to where we all started. To make a JAMstack environment complete, you need some level of a static-site generator. The players most commonly utilized are Jekyll, Hugo, MetalSmith, and Gatsby.js, to name a few.
  
  The static site generator is where most of the JAMstack magic happens. These generators tie together the coded efforts that utilize JavaScript, make the necessary API connections, and integrate them with markup to produce static website files. From there, they aid in distribution of content to the destination of your choice.
   
• Hosting: Hosting JAMstack-produced websites is so easy, it’s almost laughable. True static websites that don’t require server-side connectivity can simply be hosted on a content delivery network (CDN) such as Amazon’s S3, or similar products. More on this in the next section.

Of course, we’re looking at the above application as a typical project that an executive would be concerned about—an informational website or a lead-generation project, for example. There are literally hundreds of other ways to use these concepts, most of which fall outside of our immediate area of concern.

JAMstack Advantages

Now that we understand what JAMstack is all about, let’s dig a bit deeper into the true advantages of the platform and why one would want to build their project this way.

• Security: Security is a major factor that often leads executives to consider a solution like JAMstack. The fact is, the points of entry for an attacker when you use these solutions is minimal. The website is static; as such, the host handles most of the security concerns for you as part of their services. You are basically outsourcing your security concerns to Amazon—not a bad partner to have looking out for you. Provided you can maintain your CMS in a secure manner, have the proper authentication of your API (or just lock it down away from the world), and keep your account locked down with your CDN, security is more or less handled for you. This is as opposed to your typical CMS platform, which requires patches and updates on a regular basis to maintain a secure ecosystem. Peace of mind is valuable, especially when your company’s reputation is at stake.
   
• Simplified Content Management: The CMS industry is massively broken. Vendors are trying to outdo each other by launching feature after feature, 90% of which you won’t ever use. Open-source projects appeal to developers who hail them as the best solution ever—that is, until the next one comes around. The advent of the JAMstack philosophy has simplified content management. Headless systems take us back to the concept of clean, future-proofed content that makes your life easier, removing all of the noise, distractions, and complexity of the monolithic solutions. Amen!
   
• Cheap, Scalable Hosting: As we mentioned, the ability to host static websites on a CDN introduces the concept of cheap, scalable hosting. To scale monolithic platforms, you have to talk about load balancing web and database servers, introducing costs in both bandwidth, server leases, and bandwidth. These new static solutions can be easily hosted via CDN, which is going to save enterprises on all of the above-mentioned solutions. Plus, most CDNs are charging cheap rates for bandwidth, as their business is so competitive and commodified. Win/win.
   
• Static = Serious Speed: This should appeal instantly to lead generation, e-commerce, and SEO-minded marketers. Static sites can’t be beat when it comes to load time and performance. Without those backend database calls that rely on bloated CMS platforms, sites load at speeds that separate them from their competition and are looked upon kindly by search engine crawlers.
   
• Agnostic: These solutions can be back-end stack-agnostic. This means if your company has technical requirements that are stringent, you are still in luck. Back-end APIs can be spun out of almost any tech stack, and headless systems are either natively available in the language of choice or you can simply utilize enterprise-scaled headless providers, removing any need for your technical team to be involved in the ongoing hosting and maintenance of the CMS. Less internal headaches = quicker time to market.

JAMstack Disadvantages

Of course, there are always negatives to any approach…

• New & Trendy: In many ways, new technologies or approaches make executives nervous. The JAMstack concept is new, and it is still being adapted in scale. I would make two points here to mitigate this worry. First, the concepts behind JAMstack aren’t new at all. As I said, static websites date back to the beginning of the Web. Likewise, the elements being utilized are all proven (i.e. JavaScript, APIs, HTML/CSS, etc.). These are neither trendy nor new. Finally, the CMS and the static site generators, while new kids on the block, are not lynchpins in your delivery. A headless CMS that goes down won’t kill a static site, nor will a static generator that breaks down affect deliverability on the fly either. So, you have a bit of leeway to experiment with new concepts when working within this methodology.
   
• May Be Limiting for Complex Applications: Like any other technical direction, this is NOT a one-size-fits-all situation. There isn’t any such thing. There are areas where headless and JAMstack will not make sense. While it doesn’t make sense to list all of these scenarios here, it is important that before undertaking any technical project, you properly evaluate the best pathways forward for your business with a proper discovery and architecture process to “pre-mortem” your project and look for the best solution to achieve your goals and objectives.
   
• Fake News: Sorry, I had to use the reference. While JAMstack and headless are new concepts, the old, monolithic CMS providers are going to do one of two things. First, they may develop their own headless tools. Many have already. Or second, they may poke holes or criticize the approach. I’d expect many a salesperson will utilize the latter approach when discussing the JAMstack philosophy with prospects. I’m sure they will point out how their system has an API as well, but even more likely, they will attempt to diffuse the energy that is trending towards this concept. Take this as a sign that the technology is credible, but be prepared to defend the concept.
   
• It’s More Than Just an API: As I just mentioned, vendors will tell you they have APIs too. But this concept requires more than just an API. It requires a comprehensive approach to modeling your content and data to match the methodology. You may not be ready for this, nor may your organization be.
   
• More Dev Support: Make no mistake about it, this approach requires more dev support for iterative improvements. This is not true for content changes, but functionality tweaks aren’t so easy as installing a plugin with this approach. I don’t necessarily see this as a giant negative, as you’ll still be saving on maintenance and upkeep while avoiding catastrophic security blunders. But you will need the help of an ongoing development resource to iterate your site over time to introduce new features and capabilities. But ideally, this is how it should be anyway. Over time, it allows you to iterate not just new features, but new technologies, stay ahead of the curve, continue to improve on your UI/UX experiences, and maintain a relationship with technical resources that can help you see trends before they make it to the C-level.
   
• License Fees: Depending on how you plan to manage content, you will deal with ongoing license fees. Headless providers are utilizing SaaS concepts for charging license fees. Some have flat rates, some have usage fees. But either way, this is an ongoing relationship, not a one-time cost. The flipside to this disadvantage is, again, the complete lack of any responsibility when it comes to maintenance. They will handle hosting, scaling, uptime, and security patches. In many ways, this negative may actually be a positive, as there could be ROI to be had.

Things to Remember

It’s a Concept – Not a Library

So often, I speak to non-tech-savvy executives who ask me questions such as: “Will you use the JAMstack library?” Well, it isn’t a library, but a collection of tools tied together as a concept…

It’s important to know the difference because confusion about what it can or can’t do will influence the conversations you have with developers. Much like “Progressive Web Applications,” which was another set of guidelines but not a library, JAMstack isn’t any one set of code. Rather, it’s an approach to solving problems.

That is a big distinction versus, say, Node.js, which is a library. JAMstack can involve any number of different technologies or methodologies and still be within the realm of what the concept encompasses.

One Size Doesn’t Fit All

JAMstack may sound amazing, and in many ways, it is a groundbreaking new way of looking at web development, content delivery, and web hosting, but it doesn’t fit for all scenarios.

As I mentioned above, the best way to know for sure is to undergo a thoughtful, comprehensive discovery process to get a sense of how your website or application should be built. It could be that your site would benefit from the current norm, such as a monolithic system. Or perhaps JAMstack is, in fact, right up your alley.

Technology choices should always be made based on business requirements, not what’s hot at the moment. Developers are way too often skewed toward always recommending the hottest and trendiest platforms and methods. Always offset those opinions with your own due diligence and the advice of an expert practitioner who is not married to any one approach.

My Take

My technology recommendations are typically more conservative than the traditional technologist. As I’ve said before, my role is translating business requirements into technological solutions. In this way, the JAMstack and headless, API-driven CMS solutions make definite sense for quite a few use cases.

If you are running a lead generation, informational, marketing driven-site, this is a good solution, provided you don’t have deeper requirements such as user login areas or sophisticated e-commerce.

I’m also very prone to advise customers who are maintaining content for news, publications, video, or photo-driven sites to begin contemplating this level of architecture. It will allow for future multi-channel adaptation and expansion, and will allow you to migrate away from monolithic solutions to architectures more capable of maintaining future-proofed content.

Resources

If you are interested in learning more about JAMstack, check out these resources:

• JAMstack Radio: Not for the tech-faint-of-heart, this podcast breaks down JAMstack and various implementation strategies very well.
• JAMstack website: While I wouldn’t say any one organization is responsible for JAMstack as a concept, this centralized web presence breaks down what JAMstack is and isn’t meant for.
• JAMstack Gitter Community: A great place to communicate with other developers and technologists working within the JAMstack ecosystem.

If you’re interested in static site generators, check out:

• Gatsby.js
• Jekyll
• Hugo
• MetalSmith

Best of luck with your research!