From LAMP to JAM

Let’s walk through how the JAMstack came about from previous popular architectures.

Everybody remembers the LAMP stack:

L: Linux

Linux A: Apache

Apache M: MySQL

MySQL P: PHP

This architecture was super common years ago, and was setup by hosting a server and installing instances of all four of these technologies. The challenge was that once you had these setup, you still had to maintain them with patches and OS upgrades. You also usually setup some kind of logging or alert system that potentially lead to a maintenance headache.

Next, came the MEAN stack:

M: MongoDB

MongoDB E: Express.js

Express.js A: Angular

Angular N: Node.js

This was better as the technologies were much more lightweight. Also, if you notice the MEAN stack is all pretty much JavaScript (except for MongoDB of course). This made development easier, and potentially required less resources than what was required for a LAMP stack implementation. However, you still usually required a server for the backend and frontend. At a minimum, a server with running instances of your frontend, backend, and MongoDB for database storage.

Now, this brings us to the JAMstack (directly quoting from Astasia’s post):

JavaScript (J): JavaScript running entirely on the client handles any dynamic programming during the request/response cycle (e.g. Vue.js, React.js).

JavaScript running entirely on the client handles any dynamic programming during the request/response cycle (e.g. Vue.js, React.js). APIs (A): Reusable APIs accessed over HTTP with JavaScript abstract all server-side processes or database actions (e.g. Twilio, Stripe).

Reusable APIs accessed over HTTP with JavaScript abstract all server-side processes or database actions (e.g. Twilio, Stripe). Markup (M): Templated markup should be prebuilt at deploy time, usually using a site generator for content sites, or a build tool for web apps (e.g. Gatsby.js, Webpack).

Here with the JAM stack, we can capitalize on the benefits of JavaScript and the lighter weight frameworks without the maintenance headache. The basic setup enables developers to focus on writing their code, but without all the headache of setting up a server, hosting, etc.

After hearing John Papa’s talk and reading Astasia’s article, I realized that I had already been coding JAM stack apps for the last year with Firebase.

Firebase lets you develop apps without the need to worry about a backend and a frontend, etc. Of course, you could build out a traditional architecture with what Firebase offers you. However, providing APIs for authentication, a database, file storage, and hosting all make your life much easier when building applications.

I’ve actually written quite a bit about firebase and recommend checking out the following two articles from Angular-In-Depth: