Practical JAMstack: Blazing Fast, Simple, and Secure Web Development, the Modern Way

© Frank Zammetti 2020

F. ZammettiPractical JAMstackhttps://doi.org/10.1007/978-1-4842-6177-4_1

1. What Is JAMstack All About?

Frank Zammetti¹ 

(1)

Pottstown, PA, USA

Welcome, dear reader, to the book!

I’m sure you’ve heard about this JAMstack thing – or else why would you have bought this book?! – and clearly, you’re interested in learning about it.

Well, that’s precisely what I aim to help you do!

We’ll begin by discussing what JAMstack is, how and why it came about, the pros and cons of JAMstack, and what it offers you as a developer and as just an everyday old website user too. Then, before long, we’ll get into building some real-world projects (that’s where the practical in the title comes from) that, while nothing Earth-shatteringly complex, will provide you real hands-on experience with JAMstack. We’ll deploy these projects on the Web for all the world to see too, gaining you even more experience and understanding about how JAMstack makes this far more straightforward than it used to be, while also providing many additional benefits including excellent performance, and enhanced security and SEO (Search Engine Optimization). In the process, you’ll learn about many concepts and techniques, all the things that make JAMstack so appealing, and gain a solid foundation from which to go forth and build your own projects.

So, sit back in a comfy chair, pour a nice cup of your favorite beverage (and maybe some snacks – a rumbling tummy is bad for learning!), and join me for a journey into a new way of doing web development…

…a new way that, in many ways, is just about as old as it gets!

…But First, a History Lesson!

In the beginning – and by that, I mean the ancient days of the mid-1990s – there was the World Wide Web, or WWW, or the Web. And it was good.

Actually, no, it really wasn’t!

We had mostly text-only sites (see Figure 1-1), unless you were on AOL (America Online), which was actually worse, in many people’s estimation! Graphics were rather primitive, where they were present at all. Animation, when there was any, mostly came in the form of pretty awful animated GIFs, or if you were lucky, RealMedia video streams that looked like someone was hand-drawing each frame as you watched!

Figure 1-1

Yes, kiddies, the Web really did used to be nothing but text!

For most users, though, it was an exciting time because it was their first exposure to online connectivity of any sort, even though it wasn’t what many people would realistically subjectively call good. When it’s all you’ve got, though, and you have no frame of reference for anything else, it looks fantastic. And, it really was in some important ways! Information at your fingertips (albeit more difficult to access than it is in the Google world of today), contact with people all around the world. That’s good stuff, even in a primitive form.

And, for us web developers, it was awesome in some important ways too.

Building a website was as easy as opening Notepad on the just-released Windows 95 and hacking together some HTML (Hypertext Markup Language). Then, you’d fire up Netscape Navigator to view it (or edit using Vim on Unix and viewing with Lynx – it doesn’t matter, the point is it was just plain text with no special tools involved). You’d make some changes, reload the page, and see your handy work immediately. It was a straightforward but surprisingly effective workflow in those simple, early days.

Then, when you were ready to unleash your handiwork on the world, you would just hop on FTP (File Transfer Protocol), upload your HTML files to a web server, plus whatever images might be needed if you were one of those fancy graphical sites, and you were good to go. You might not even have to deal with the web server yourself: sites like GeoCities hit the scene before long and made it even easier to do everything through a simple browser-based interface. Though, GeoCities was its own kind of hell because while it was great in that it let anyone produce content on the Web, it let anyone produce content on the Web – gotta take the good with the bad, I guess!

And if you wanted to see how someone did some neat trick you saw on some site? You would just right-click, View Source, and there it was! No obfuscation (usually), no incomprehensible library needed, only naked HTML, JavaScript, and CSS (Cascading Style Sheets) to learn from (or, let’s be honest: to steal!).

Now, the flip side of this ease is that it was a terrible time in terms of browser compatibility, and CSS was incredibly primitive. JavaScript was a buggy mess that varied from browser to browser, and performance wasn’t a primary concern of anyone (although it tended to wind up being pretty good simply because less was being transferred and less was being done on a given web page). Just getting things working and out there was all that mattered to most people. And SEO? Well, search engines were extremely primitive at that point, where they existed at all, so it wasn’t much of a concern.

Note

And even earlier on, there literally were no search engines! I can remember buying a book, much like a phonebook, that listed sites in categories, and that, in conjunction with your fingers to flip through it, was the search engine, in effect!

It wasn’t all roses and rainbows, that’s the point, whether for users or developers.

But still, it was ultimately as simple as a bunch of HTML pages linking to each other, with no complicated tooling to put it together. There wasn’t much more to building a website than that early on, and there wasn’t much more to hosting it than uploading it somewhere.

Today though? UGH!

You have to install a seemingly never-ending cavalcade of different tools, some of which you’ve likely never dealt with previously because they seem to come and go like the wind. Some will be general purpose, but some may well be specific to the library or framework you’re using (oh yeah: and you probably are using some library or framework!). Then you have to execute some obtuse maybe half a dozen commands to produce some skeleton code that has a million different dependencies. As a result, your website has to be developed in a specific, unique way, and you’ll struggle to understand it, especially when things go wrong, because you didn’t write most of the meat of the code that makes up your website yourself. And it’s all to produce a website that is as complex sometimes as the space shuttle was! Then, you have to create perhaps an S3 bucket (whatever that is). Then you build some Lambda functions and maybe create a RESTful interface (again: what?!). Then you upload the code via SSH (Secure Shell, which might require you to know about certificates) and define your deployment model. You check it all into Git and struggle to understand some complex SCM (Source Code Management) workflow. And so on, and so forth, until your head is smacking against the wall and it actually feels better than the work you’re trying to do!

And, at the end of it all, you have a website that quite possibly doesn’t even perform all that great because it’s loading so much content and making so many requests to a server that is servicing so many concurrent requests, each of them critically requiring some complex processing and rendering logic to occur on the server before the final content is delivered to the browser for display to the user!

It’s incredible that anyone can get anything done and that sites perform even as well as they do, despite so many admittedly amazing tools to do a large chunk of the work for you!

At some point, someone threw up their hands and declared: "there must be an easier and better way than this!" (see Figure 1-2).

Figure 1-2

What I imagine Mathias was feeling when he came up with JAMstack

The time was roughly five years ago (2015-ish), and that someone was a guy named Mathias Biilmann, CEO and founder of a company named Netlify, and the easier and better way is JAMstack.

Okay, History Is Nice, But What Is JAMstack?!

Put simply: JAMstack is fundamentally a philosophy. It’s an approach, a way of thinking, a set of principles, and best practices. It’s an architecture, if a somewhat reductive and minimalistic one.

It’s not really about specific technologies, per se. Instead, it’s about going back to the very basics of web development: pre-rendered HTML documents, and hosting them in a way that doesn’t require a vast infrastructure or investment in hosting hardware (whether physical or virtual), at least not directly by you as a developer. Most usually, this last part means a CDN, or content distribution network.

It’s the static web, in other words, much like it was in the beginning. It’s client-focused development, where client means the combination of the machine and browser that is accessing the website. It’s a new way to look at things that provides us a new paradigm that, paradoxically, is a return, in many ways, to the paradigm that started it all!

If you’ve ever heard of the MEAN stack (MongoDB, Express, Angular, Node), or the LAMP stack (Linux, Apache, MySQL, PHP) , then you have a good idea what JAMstack isn’t: it’s not a specific set of technologies that, bolted together, provides a particular foundation to build a website on. At least, none beyond what the Web itself depends on at least, namely, HTML, CSS, and JavaScript. JAMstack doesn’t prescribe you use a specific server, or database, or templating language, or anything else. In fact, it doesn’t mandate that you use those things at all (though you can and, frankly, most likely will for anything but the most trivial of websites).

With JAMstack, rather than every user action resulting in a call to a server that then renders a new page dynamically, all pages in a JAMstack website are static HTML pages that the user navigates between. And yes, if you’re wondering if you can do SPAs – single-page apps – under the JAMstack banner, the answer is yes: your site/app will have just a single static HTML page.

Now, that may sound incredibly limiting at first because it seems like JAMstack means you can’t have a dynamic site. However, it turns out it doesn’t have to be because you still have JavaScript at your disposal, which means that you can always make calls to remote services to get data and insert it dynamically into the page. Also, although your pages are static HTML documents, the content it displays doesn’t have to be. It’s just that the page’s markup and the data aren’t being constructed on the fly by the server and sent to the client all the time because typically, there is no server when dealing with JAMstack, none you yourself deal with at least. You are essentially pre-rendering pages when working the JAMstack way, just like the server would have, but before the content is served now, so it only happens once at build time. And then, at runtime, you still have JavaScript to introduce even more dynamic content .

So, static in the context of JAMstack doesn’t mean unchanging, it just means that when and how changes occur is rethought.

To the extent that JAMstack is about specific technologies, the three pillars of JAMstack, as shown in Figure 1-3, are contained in its name, namely, the JAM part: (J)avaScript, (A)PIs, and (M)arkup. As Mathias Biilmann himself put it, JAMstack is

A modern web development architecture based on client-side JavaScript, reusable APIs, and prebuild markup.

Figure 1-3

In deference to Spinal Tap, This Is JAMstack!

But, critically, JAMstack doesn’t dictate how you use those. It doesn’t demand you use this framework or that, any specific library or toolkit, nor does it push you to architect your app in any particular way. In fact, a JAMstack website doesn’t even have to use all three of those pillars. They can use one of those, two of those, or all three of those. And again, how they’re used is up to you.

Every website is going to use markup, of course, in the form of HTML. But, whether you need JavaScript and APIs (application programming interfaces, which are the remote services your JavaScript calls on to perform more complex functions and access data) is up to your requirements. You can still have a JAMstack website without APIs, and you could even have a JAMstack website without JavaScript, which you’ll be seeing shortly, just to drive the point home.

Where this all differs from more traditional web development is largely in the workflow. In a traditional workflow, the process of building the website and hosting the website is, in a sense, tightly coupled activities. When a user requests a page, the target file on the server, be it PHP, a Java servlet, or something else that can produce content at that time, is processed by some engine. This processing most usually involves some complex set of actions like accessing a database, or perhaps calling on a remote system to get some data. Eventually, the data is inserted into a template, and the resultant HTML returned to the browser. There are various forms of caching involved along the way too, many layers to consider before the content gets to the user. Note that the HTML the browser receives never exists as a static entity, which is why I say that building the website, which happens dynamically, is coupled to the hosting of the website. Put another way: it is both built and delivered to the client at the time it is requested.

On the JAMstack (which is frequently how it’s termed when you build a JAMstack site: on the JAMstack), that HTML file already exists in its final, servable form. It was built previously and is hosted, most typically on a CDN rather than a server. When it is requested, no processing is required; it is simply sent to the browser immediately. In that way, the building of the website and the hosting of the website are decoupled: the page was previously built and then is served when requested.

Also typical of the JAMstack flow is that the core content, that is, the precompiled HTML pages, are stored in Git. While using an SCM system isn’t a requirement, and using Git specifically isn’t a requirement either (it could be Subversion, or other Source Code Management – or SCM – system), it’s quite typical. The benefit of this is that, first, your website is version-controlled. This means that it’s easy to have collaborators, and you’ll be able to view the history of any given file, as well as keep collaborators accountable for those changes.

Another key benefit is that there are services that can be used (which we’ll get to see in later chapters) that can monitor for and react to the changes to your Git repo when you push them and automatically deploy them out to a CDN. In the process, cache invalidation is automatically done so that clients get fresh content immediately. As part of this concept, deployments are always done atomically, meaning that the entire website is pushed out as a single unit. You aren’t trying to deploy things piecemeal; it all goes live together, as a full snapshot of the site, which means that the content is consistent globally.

Essentially, everything I’m describing here leads to a continuous deployment model : your website is always live and updated almost instantly when using certain JAMstack-oriented services (which you’ll see in upcoming chapters), without you lifting a finger to make it happen! Figure 1-4 shows you this basic flow.

Figure 1-4

The basic, typical, JAMstack workflow

At the end of the day, a JAMstack website is likely to be any website that isn’t built with a server-side Content Management System (CMS) like WordPress, Drupal, or Joomla. It also likely isn’t a single-page app that specifically uses isomorphic rendering techniques to build the views of the website on the server at runtime. And, it probably isn’t a monolithic application that runs on a server like Tomcat, WebSphere, GlassFish, or similar application servers, or that uses things like Node or Spring Boot to be its own server, in essence.

Anything else is pretty much fair game on the JAMstack!

Fisher Price’s My First JAMstack Website

Now that you have an idea what JAMstack is and how it came about, let’s talk briefly about how you actually build a JAMstack website, and we’ll start with an example:

Open Notepad (or your plain text editor of choice).

Type the following:

    

    JAMstack Hello, World!

Save the file and then open it in your web browser of choice.

Yes, you’ve literally just created a JAMstack website! It’s not gonna win any awards, but it might be the simplest example of something that qualifies as a JAMstack app. It uses markup (though not JavaScript or APIs), and it can be hosted on any CDN without any sort of server-side requirements.

Of course, nobody but you can see it as it stands now, but that doesn’t change what it is. And, if you did upload this to a CDN right now, then you’d have a live JAMstack site!

Naturally, more complex sites require more than this, and frequently you’ll find that JAMstack sites are built with what’s called a static site generator, or SSG. This is an application that can suck in templates and various forms of source data content, and spit out final, compiled HTML files that are ready to be hosted on a CDN for end users. This is something we’ll look at in a lot more detail in the coming chapters, but for now, it’s enough to know that (a) such a thing exists, and (b) you in no way must use them to do JAMstack development.

Advantages, Disadvantages, and Misconceptions

Okay, so you have a little history and historical context now, and you should have a clear picture of what JAMstack is, but why would you want to use it? That’s a whole separate question! And, as a corollary, why might you not want to use it?

Let’s tackle the advantages of JAMstack first because they are simple, obvious if you think about it, and arguably far outweigh any disadvantages there might be:

Scalability – A JAMstack app doesn’t require a server to run, which means it can be hosted easily and cheaply on CDNs. That is, in fact, the most common deployment model (note, however, that using a specific server doesn’t suddenly make it not JAMstack either). CDNs are inherently scalable facilities that distribute the load around the entire world, and which can adjust to growing load quickly and easily, all without any intervention on your part. The very nature of a JAMstack website means that they are light in terms of resources on the server side of the equation (and they often are light on the client side too, although that’s actually up to what you do in your code). All of this contributes to making a JAMstack website more scalable and able to handle load efficiently. If you’ve ever heard the term serverless, this is what I’m describing: you don’t concern yourself with the infrastructure involved in hosting your website – someone else does that for you – it’s just a place to put your content, and all the details about actually serving it are mostly abstracted away from you.

Cost – As alluded to in the previous point, JAMstack sites usually require far less delivery-side resources in terms of servers and databases and such. This makes hosting them cheaper, by and large, and sometimes massively so. Obviously, this can vary depending on what your website must do to function, but it is typically true.

Security – Much of the exploits suffered by websites these days are due to flaws on the server-side. Sure, there is a whole class of exploits that are client-side in nature. Still, even those will typically require some sort of breach in server-side security. Cross-site scripting, for example, is generally considered a client-side exploit, but if HTML pages aren’t generated on the fly by a server, then it becomes all but impossible to implement such an exploit, just as one example. As such, JAMstack sites are almost always more secure than are non-JAMstack sites. To put it another way, JAMstack reduces the attack surface of your app, and a smaller attack surface is always a very good thing as far as security is concerned.

Performance – A pivotal benefit to JAMstack is that with no server in the mix generating content on the fly, performance can be significantly better on the JAMstack than on more server-bound applications. There will, of course, be some dependency on the client performing well, but that’s always true whether on the JAMstack or not. If half of the performance equation – what the server has to do to service a request – is all but eliminated, then assuming the client isn’t massively underpowered, performance is automatically going to be better, and there’s a good chance it will be to a significant extent. Time-to-first-byte is a common metric talked about here that is used to describe how long it takes before the content provider responds with the first byte of content to a client request. JAMstack boasts an almost instantaneous time-to-first-byte advantage over more traditional server-based architectures.

Developer experience – Most developers that work with JAMstack for even a little while will inevitably tell you that things are just simpler and more straightforward for them. Debugging typically becomes easier because what you’re debugging on the client side doesn’t change – remember, it’s static content when served. That eliminates a lot of questions from the debugging cycle. It’s also easier to comprehend the bigger picture of a website on the JAMstack for the same reason: when you decouple the build and hosting concerns as previously discussed, you’re back to just static pages and not trying to figure out when content gets rendered, what renders it, and how all those pieces get put together in real time. They aren’t getting put together in real time, which is just easier to understand for any developer!

SEO – Because JAMstack websites are just static content, and because static content is much easier for search engine spiders to crawl and index, they naturally provide better SEO value (though, of course, you still have work to do to make sure the right terms make it into the index). A website that renders content dynamically presents challenges for indexers that a purely static-content site doesn’t.

It would be dishonest to say there aren’t some negatives to JAMstack. However, they tend to be at least somewhat debatable and not nearly as numerous or as weighty, so to speak, as the positives. Still, let’s talk about the (possible) downside to JAMstack:

Developers are required – Because of the way JAMstack works, a developer must be involved for any content update because it involves rebuilding the entire site (in whatever way the site is built). Now, it’s entirely possible for content creators to supply the content in a nontechnical fashion that the build process consumes to produce the static HTML in the end (and you’ll see some of that in the coming chapters). So, the developer could just be a glorified button-pusher in a sense! But, it’s almost guaranteed that a developer will have to push a button in the end. For some use cases, that’s going to be seen as a negative because developers ain’t cheap!

Update frequency – Largely because of the previous bullet, JAMstack isn’t a great choice when you’re dealing with a website that needs to be updated frequently. If you were working on a website for a large news organization, like CNN or MSNBC, for example, then JAMstack would almost certainly be a counterproductive approach. There, you would very much want content creators to be able to upload content directly to the system in some fashion (whether a literal upload or via some administrative app creation interface) and have it automatically made available. That pretty much can’t happen when working the JAMstack way (it’s not 100% impossible, but it’s far from optimal to force it into JAMstack). For that, you’d be looking at a more typical server-based approach that reads data from a database or CMS of some sort to produce the always-dynamic site.

Steep learning curve – This is one of those highly debatable ones because I, for one, don’t really perceive a steep learning curve to JAMstack, but some do. My opinion is that any steep learning curve is almost entirely a direct result of it not immediately being clear what JAMstack is in concrete terms! As developers, we tend to think there’s more to a new term than there sometimes is, and I believe JAMstack is an excellent example of that. You think of a stack as being some collection of technology, each with its own learning curve that, when combined, makes the whole stack challenging to comprehend at first. That’s not the case with JAMstack: we’re really going back to basics with it and removing a lot of the complexity. But, our brains have trouble accepting that at first (I know mine did when I first encountered the concept of JAMstack). I hope that this chapter has done a good enough job explaining things that you don’t experience this and so find the learning curve not at all steep, at least, not any steeper than non-JAMstack development.

You’ll notice …and Misconceptions in the title of this section. What misconceptions, you ask? Well, there’s one key one, and that’s the misconception that JAMstack websites can’t be dynamic. It’s a logical thought: we are expressly dealing with static pages of HTML content, so how in the world can they possibly be dynamic at the same time?

The short answer is mostly down to the A