Web sites have traditionally been powered by monolithic architectures, with the front-end of the application tightly coupled to the backend.
Monolithic applications are opinionated about how tasks on the server take place. The opinions they enforce have shaped how web development is approached and the environment within which we now work.
Widespread and trusted as the de facto way to build for the web, these tools have had a profound impact not just on how sites will perform but also on how efficiently they can be developed and even on the developers' mindset.
The lock-in created by this is tangible. These applications dictate the approach to many facets of a web development project in ways that are not always appealing to the web development community at large. The selection of one monolithic app over another is often based on how long their lists of features are. A tendency to select tools based on what is best in class or the most popular in the market can often overlook a fundamental consideration: what does this project need?
By regularly asking ourselves these questions, we believe that there is a level of overengineering present in web development today. This overengineering impedes the use of proven, effective processes, technologies, and architectures.
Can we take action to improve this situation? Can we attack the limited flexibility, performance concerns, scaling challenges, and security woes imposed on us by legacy architecture?
The freedom to do good work—to design the exact experiences we want for our users—is regularly compromised by complex monolithic applications.
Over the past few years, there has been a rising appreciation for optimizing front-end code's dramatic performance gains. Yet, while recognition of the value of strong front-end development has grown, the platforms developers use have often not afforded the freedom to bring front-end skills fully to bear.
The architectures imposed by monolithic applications can undermine our ability to utilize the latest technologies and even affect our development workflows. This inhibits our efforts to protect critical aspects of software development fundamentally.
Website performance is integrally essential to the success of internet-delivered content. Many studies exist that conclude that account and conversion are tightly linked. One such study concluded that a single second delay in load time could hurt an eCommerce site's conversion by 7%.
As it happens, monolithic apps are rarely conducive to superior site performance. They need to generate and deliver HTML every time a new visitor arrives on the site. This significantly slows down page load time.
But performance isn't dictated by speed alone. Because monolithic apps are large, it can be challenging to define architectural boundaries. The code is so interconnected that fixing a bug, updating a library, or changing a framework in one part of the app can break another part.
Caching is another essential part of overall site performance—and it's one that's notoriously difficult to get right with a dynamic site. Suppose a site is built on a monolithic app. In that case, it's possible that the same URL can return different content depending on a variety of parameters, including whether a user is logged in or the site was previously running a split test. Being able to deliver a predictable experience to end users is vital.
Because monolithic architecture requires the page view to be generated for every visitor, infrastructure needs to be scaled in anticipation of site traffic. Not only is that expensive, but it's also tricky to get right. Teams end up over-provisioning their infrastructure to prevent downtime or risk a crash because there is no clear separation between the infrastructure required to generate and manage the site and that needed to serve the site.
When the same application that builds the page views or lets authors manage content also needs to be scaled to handle traffic spikes, it's impossible to decouple these facilities to scale and protect each piece of the infrastructure to its needs.
In this scenario, the considerations that influence the technical architecture of a site suffer from being lumped into one large system. In computer science, we recognize that the costs of writes and reads can be very different. Yet, monolithic apps bundle these features together into the same application, making them difficult to design appropriately.
The approach to designing a system that allows for hundreds of millions of reading operations is very different from that of a system that will enable a similar number of write operations. Is it wise to combine these capabilities into the same infrastructure and demand that one feature's risk profile influences that of another? And are those features likely to encounter similar traffic levels?
There are ways to distance the users visiting your site and the complexity that generates and delivers that site. Without such separation, the scale can be challenging to achieve.
We want to ensure that as we're evaluating why monolithic apps are no longer serving the growth of the web, we're careful not to insult the hundreds of thousands of development teams that chose to implement them. We've been that team. You might be on that team right now. One of the ways to avoid this is by merely looking at the facts. And when we talk about security, the points are difficult to dismiss.
According to recent estimates, WordPress powers 29% of the web. Joomla and Drupal follow as the second and third most popular content management systems, respectively. That makes them a prime target for bad actors.
The availability of these products as hosted services can help absolve us from some of the responsibilities to secure the underlying infrastructure. Still, in self-hosted instances, we must shoulder all of that burden ourselves. In either case, there are many attack vectors, and the introduction of third-party plugins can expose us to further risk and make things even more challenging to secure.
Monolithic apps like WordPress, Drupal, and Joomla combine every single component and plugin of a web project's architecture into a single codebase. In turn, it creates a massive surface area for malware to penetrate. Not only is the attack surface area extremely
large, it's also exposed every single time the site is built because any plugin the site uses must execute each time the page loads for a new site visitor, magnifying the risk.
With that volume of distribution, injecting malware into a single plugin can mean massive distribution. A recent attack caused 12 million Drupal sites to require emergency patching.
And there's one more catch: in monolithic apps, plugins are tied directly to the core framework. Because they're notoriously insecure and require frequent (and often buggy) updates, hastily updated plugins run the risk of breaking the entire site. Maintainers are left to choose between security patches and the risk of breaking site functionality.
The JAMstack, at its core, is simply an attempt to give a name to a set of widely used architectural practices. It gives us one word to communicate a broad range of architectural decisions.
A large set of terms for the different pieces of these new software architectures began to appear: progressive web apps, static sites, front-end build pipelines, single-page applications, decoupled web projects, and serverless functions. However, none of them captured the move to a new architecture encompassing content-driven websites, web applications, and all the interesting hybrids between the two.
In today's web development environment, the "stack" has moved up a level. Before, we used to talk about the operating system, the database, and the webserver when describing our stack (such as the LAMP stack and MEAN stack), but with the emergence of new practices, the real architectural constraints became the following:
These components became the JAM in JAMstack.
The choices you'll have to make along the way to create the appropriate setup for your projects include the following
With no server or database to configure, a JAMstack project is mostly a simple folder structure full of text files. The contents of your JAMstack project will usually include the following:
The most significant choice to make - the right Static Site Generator
It's possible to use a site generator without knowing the programming language used to create it. For example, even if you don't know anything about the Go programming language, Hugo is an excellent choice because you can download and install it as a binary application with nothing else to set up and no programming knowledge required.
However, the exact syntax used varies and is mostly a matter of personal preference. Developers prefer the minimalist style of a language like Jade or Pug—both of these forgo brackets and closing tags in favor of indentation. Other developers prefer template languages like Handlebars and Liquid that look as close to traditional HTML as possible.
The speed at which your site generator can build out each page becomes essential as your content grows. A site with a handful of pages can take just milliseconds to build, whereas a site with archives of content can take several minutes to complete building. Because each change you publish will run the build process, speed is an important consideration.
Every website begins with content. On Content Management System (CMS) systems like Drupal or WordPress, sites manage content in a database, and editors use an admin interface to write and save the content to the database.
On the JAMstack, there are a few content approaches.
For many JAMstack sites, the content couldn't be more straightforward: it's merely a folder full of files that live directly within the project with the templates, plugins, and other assets. Creating a new file in the content directory will create a new page after the site is published. Changes are made by editing the content files in a text editor and then committing the changes to the Git repository. Each file's name and the folder it is in will determine its URL path after the site is generated.
Not all your site contributors will likely be developers, and using Git and text files may be an unfamiliar experience. However, you probably have experienced how a complex CMS can create an artificial separation between the content editors working in the database and the developers building the code and templates.
Because every web page ultimately ends up as a combination of content and Markup, it would be nice if you could manage them both by the same process.
Here's the clever bit: a saved change in the CMS is really made as a Git contribution behind the scenes. That's powerful because developers and editors are working in the same Git-based workstream, modifying the duplicate files using whichever method is most comfortable to them.
NetlifyCMS and TinaCMS are open source CMS that works in this manner. Forestry.io is another.
"Headless" refers to services manage only the content, leaving it up to the developer to determine how and where the site is built and hosted. More extensive projects use a headless CMS as a central content store behind their entire collection of sites and mobile apps.
For example, you might use a headless CMS for your recruiting team to manage job postings. The static site generator would then query the API during the build step, receiving a list of the job post‐ ings as JSON. It would then use templates to create a unique HTML page for each posting, plus, of course, an index page listing all the postings together.
If you have lots of content or expect your content to grow a lot over time, statically generated web pages are not the best solution. The reason is that it takes much time to build the site if you have lots of content.
When creating a huge app with thousands of pages, it can be somewhat slow to rebuild. And if you have to wait for a chunk of time when you hit publish before it goes live, it's not a perfect solution.
So if you have a site with content that you will expect to grow and grow over time, then Next.JS is the best choice for you.
Also, if you want more freedom with how you access your data, Next.JS is the answer.
The biggest differentiator is that you can pre-render pages at build time (SSG) or request time (SSR) in a single project.
With more than 700K downloads, 20K stars, and 300 individuals contributors, Strapi is the most flexible open-source Headless Content Management System (CMS). It gives developers the freedom to use their favorite tools and frameworks while helping editors to manage their content and distribute it anywhere efficiently.
By making the admin panel and API easily customizable and extensible through a plugin system, Strapi enables the world's largest companies to accelerate content delivery while building better digital experiences.
Strapi is published under a standard MIT license. All contributions made to the project via GitHub pull the MIT license governs requests. The Open Source third-party components used by Strapi are also governed by licenses that are compatible with the vast majority of standard Open Source licenses.
In addition to the main Strapi project, we have also open-sourced a component library called Buffet.js to help the community build plugins and better user experiences in application interfaces.
Managing a corporate site is hard. Marketers need to update the content regularly: new blog posts, customer testimonials, targeted landing pages, and more.
Every time, it's a new interruption for technical teams, who have to code new releases. These development cycles prevent marketing teams from freely experimenting with their website.
Marketers need full control over their corporate site.
Without leaving the Strapi UI interface, you'll be able to:
With all these considerations in mind, it is clear why the JAMstack holds so many benefits for corporate websites. So if you are indeed in the process of creating one or redesigning an old business website, switching to the JAMstack is a beneficial choice.