JAMStack; Your solution to a problem you didn’t know you had

The Problem

Does this sound familiar?

  1. You had a monolithic web application, it had everything and it’s CMS built into it, probably hosted on a bare metal RHEL based server, and likely uses your own fun little database abstraction layer you wrote one afternoon.
  2. You decided, enough was enough, and you started looking into Docker and Microservice architecture.
  3. You “rebuilt” (read: re-purposed) the monolithic chunks into a core website with all of it’s moving pieces, made the CMS headless, and in lieu of raw database connections you have your server side call out to sattelite “micro”-services.
  4. See, we put “micro” in quotes but let’s be honest with each other, there’s nothing “micro” going on here. You’re probably packing in a full ubuntu server, and your RESTful API is handling large swaths of tasks because it’s easier (and cheaper) to add a route in an existing one than it is to spin up a new hosted service bespoke to the task at hand. It’s also probably got a bunch of other dependencies crammed into it to facilitate some random tasks from months ago.
  5. You realize you’re deploying 1+gb sized containers for your website, and 500mb sized containers for your various API’s. Jenkins is taking forever.
  6. It’s all just such a bloated mess.

What if there was a super light way to build a modern website / web application?

What if there was a way to dramatically reduce complexity, and even make it potentially cheaper to host?

All these what if’s. What’s the solution?

The Solution

JAMStack.

You’ve probably heard of several stacks before, with “MEAN” and “LAMP” easily being the most prominant and popular ones.

  • LAMP = “Linux + Apache + MySQL + PHP”
  • MEAN = “MongoDB + ExpressJs + AngularJs + Node.js”

The thing about clever stack acronyms is that they wind up being very opinionated over what each letter means, and if you deviate in any way you’re no longer apart of “cool club” (even if what you switch too, shares the same letter)

Where JAMstack differs is that it doesn’t care about what tech you use, it’s a development philosophy and paradigm, where the opinions at play are about how you choose to conduct your application; and what’s better in that you barely have to change your mode of thinking to be apart of this club. For you see:

JAMstack = “JavaScript + APIs + Markup”

What does this even mean?

The acronym approach to open design philosophy is frankly a genuis move, and I encourage future stack ideas to stem from this approach instead of laser focusing on anything too specific.

JAMStack aims to let you accomplish something pretty wild: Did you know your website doesn’t need a server side layer?

it was all the rage yesteryear when hype was building around static website generators like Jekyll. But the appeal of building a pre-built static website was that hosting was simple, it was hack-proof, and dirt cheap or even free. Because all of your assets are pre-compiled and static, you no longer needed PHP / Ruby / Python / etc. You could just upload the resulting files to a directory, and point Apache or Nginx at it and call it a day. Or even better, upload the files to a CDN or public folder like an AWS S3 bucket or a (RIP) Dropbox Public Folder, and you need only adjust your domain name to point to that.

It was cool, but it presented some unfortunate limitations. Depending on size, compiling could take a while, especially if the rendering step was reaching out to API’s to bake into the pre-compiled output. You couldn’t make a tiny adjustment or correct a posts text without having to first completely re-compile the website, and deploy. Also, depending on size, uploading the files could also take quite a while, especially if your host was only accessable via FTP. Basically, it’s a cool idea, but it quickly becomes an annoying maintenance nightmare.

This is where JAMStack comes into play: It wants you to build a dynamic website off of statically served files. How is this possible?

No alt text provided for this image

JavaScript

Putting the J in JAM, the idea of using browser side JavaScript as the end all be all of building a dynamic website sounds crazy annoying and convoluted. And it used to be. But today, we are positively spoiled with choices for how to approach this.

Angular

Backed by Google, modern Angular is a full on batteries included front end client-side framework for building websites and web applications. It pulls no punches, it has everything you could want or need packed into it to hit the ground running. It’s powered by a ridiculously powerful toolchain powered by TypeScript and it’s own CLI to spin up your project into a automatically Live Reloaded Hot-Swap development environment, and for production can build in AOT mode (ahead of time compilation) and “tree-shake” away all unused bits of code into the tiniest deployable you ever did see.

Angular has a huge emphasis on siloed componentisation, supports one and two-way data binding via RxJS, has a nice Router and HTTP client, and supports a concept known as Shared Services to help deal with global state (if at all needed)

React

Backed by Facebook, React starts off small and light as purely a UI layout kit built off the back of a similar component paradigm as Angular. To make react useful to a JAMstack application, you’re gonna need to reach out and grab some extra react libraries to provide some needed functionality, such as routing and redux. How you want to build your React app is in full control to you from top to bottom. This flexibility and unopinionated nature is exactly what has made React so popular.

Vue.js

Backed independently, Vue takes the precedents set by AngularJS 1.x, BackboneJS, KnockoutJS, etc, and keeps it simple while offering scores of possibilities out of the box, powered by modern vanilla javascript. Where Angular and React can (and oftentimes do) take over a whole projects lifecycle, Vue is as easy to get going in a project as including a script tag in the page and just using it as is to build rich bespoke components.

That’s not to say it’s incapable is growing out from there, indeed the power of Vue lays in it’s ability to be as big or as little of a deal as you desire. Just need a fancy JS powered form or a fancy in-article ad display manager? Vue can and will. Need a full on rich javascript application as the first class citizen? Vue can and will.

Vanilla JS

Dont want to do any of that and prefer to write bare metal? Vanilla JS is for you. You don’t need a package manager, you don’t need a build chain, you don’t even need to download anything, it all works right out of the box.

The point of any of these is that you can’t go wrong, and they’re all compatible with the JAMstack philosophy.

APIs

This is where the magic comes into play.

Now, to have a dynamic website, like a blog or a forum for instance, you need to read in dynamic data from some kind of datastore. Usually, this would be handled inside of your application via a server side language like PHP or Python. But in a JAM world, there is no server side that powers your frontend website. Remember, this thing needs to be hosted on a static server.

All you need to do, is use your favorite method of choice for making an XHR request (XmlHttpRequest) to some kind of off-host APIs. These could be anything from Twitters API, YouTube’s API, or even your own APIs hosted elsewhere. The possibilities of data outreach are endless.

Regardless of the frontend technology you opted into, you will need to dynamically update the DOM (Document Object Model (the HTML)) with the information retrived from your API calls.

API call to the currently active profile to help populate the profile dropdown in the top right.

API call to get the list of paginated blog posts for this current category.

API call to get a list of available categories.

Here’s the magic: in a server side powered website, you’d need to make all of these calls over and over again for each page refresh. But the soft goal of JAM is to make your pages an interactive dynamic experience with as little to no hard refreshing as possible. So the profile and category calls need only beed called once, but the list may need to be re-called with new parameters if someone clicks a pagination link. This potentially reduces server and database load, and the user has no idea they’re interacting with a statically hosted website.

Markup

Unambiguously, JAM wants your HTML to be stored as is served. It does not want your HTML and templates to be rendered via a server side of anything. Your front-end application must handle all HTML DOM events.

And really that’s the long and short of it with this one.

So what do we have here as a result?

One statically hosted client side web application

none, one, or more deployed API light microservices

none, one, or more leveraged 3rd party APIs.

And uh, and that’s it. It’s hard to go much further on this topic because everything is so ambiguous.

Really the major rules to follow:

  1. Your JAM website is just one of potentially more clients to your deployed services. Treat it like one.
  2. Your JAM site cannot have a server side to it.
  3. Your services should be build light and handle a specific set of tasks (aim for less than 50mb deployable containers, base image and all, each)

Keep hosting cheap, light, maintainable.

You can host a static website for practically nothing on an AWS S3 Bucket, or for outright free on services like Netlify.

You can host your services for free indefinitely on PaaS systems like Heroku and Google App Engine

If you’re really trying to live frugally, you can use Google Doc’s API to store data in a Sheet’s page. You can probably also get away with using AWS’s DynamoDB for free if you keep the data under 1gb in size. There’s lots of options out there.

Leave a Reply

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
Notify of