Why and How to Build a Corporate Website on the Jamstack

This article was originally posted on our blog - visit www.webriq.com/blog for other great articles. You can view the article HERE

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?

Limited Flexibility

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.

Performance Concerns

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.

Scaling Challenges

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.

Security Woes

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.

Why Choose Jamstack

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.

The Jamstack put a name to all of it

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:

• JavaScript in the browser as the runtime
• Reusable HTTP APIs rather than app-specific databases
• Prebuilt Markup as the delivery mechanism

These components became the JAM in JAMstack.

How to start a Jamstack Corporate website

The choices you'll have to make along the way to create the appropriate setup for your projects include the following

• How you'll manage the project/code
• Where you'll store your content
• What software will build your site
• How your build process will be automated
• Where your site will be published
• What services and APIs your live site will use

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:

• A source folder to store your content files
• A folder for layouts and templates
• A configuration file containing the settings for the build process
• A static site generator usually added as a dependency
• A destination folder to save the final output

The most significant choice to make - the right Static Site Generator

Today, site generators are available in almost every language, including Ruby, Python, PHP, JavaScript, and Go. The website staticgen.com is a community-curated directory of static site generators, with more than 30 languages represented. Most site generators are both free and open source.

Factors to consider

One: The Type of Website

You'll find its authors create each generator with a particular type of website or application in mind. Some generators are designed for websites with complex taxonomy and thousands of pages, others specifically for blogs, others for documentation, others for progressive web apps (PWAs), and richly interactive apps for which most content and navigation are loaded and handled via JavaScript.

Two: The Programming Language Used

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.

Jekyll also does not require any specific Ruby experience to make fair use of it, but you first need to have a working Ruby installation to get it to run on your computer. Gatsby, another popular site generator that uses the React JavaScript framework, requires you to have a recent version of Node.js installed. You get the idea: a little experience with the tooling around the language can help.

Three: The Templating Syntax

You will spend the majority of your time creating and modifying HTML templates, CSS, and JavaScript. Take a close look at the templating languages your chosen static site generator supports. All templating languages augment traditional HTML markup with new functionality like reusable code blocks, if statements, and loops.

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.

Four: Speed

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.

Hugo is notoriously fast at building site pages, thanks to Go's multi-threaded architecture. Other site generators, by nature of their design goals, build both static HTML and a JavaScript bundle for each page. The JavaScript will reduce load times for a user navigating around the site after it is on a CDN, but the extra work involved increases build time significantly.

Five: Developer Tooling

A site generator's core goal is to transform content into HTML, but as you know, a site always contains other assets like CSS, images, and JavaScript. Modern front-end web development is starting to look like traditional software development, with toolchains to prepare and compile production assets.

Strategies for Managing Content

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.

Text Files

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.

Git-Based CMS

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.

There's now a new generation of CMS software that does precisely this, managing content as files in Git rather than a database. Usually included in your project as a single-page application (just an HTML file with some JavaScript dependencies), a Git-based CMS allows users to log in to a familiar admin interface to edit content and preview and save changes.

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 CMS

"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.

All headless CMS services provide an API used to pull the most recent content during the build step (and dynamically using JavaScript as the site runs).

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.

A Corporate website on Nextjs and Strapi

Why Nextjs

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.

Why Strapi

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.

As a headless CMS, Strapi provides backend functionalities for websites and apps built with the JAMstack(JavaScript, APIs, and pre-rendered Markup, served without web servers). Strapi supports most databases, both REST and graphQL API, and is designed to work with the most popular front-end frameworks, including Gatsby, Nuxt, Next.js, or another static site generator. Our main objective is to become the most flexible and extensible headless CMS on the market.

Strapi & Next.js Corporate Site

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:

• Create new pages and nested pages
• Design your pages as you wish using our prebuilt UI sections
• Update the links and logos from your navbar and footer
• Display notification banners on your site
• Preview your pages before publishing them

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 Jamstack is a beneficial choice.