In a previous post on how this blog works, I referred to Gatsby and GraphQL. This is a specification of a generic stack and pattern called the JAM stack.

JAM stack is an abbreviation for Javacript, API(s), and Markup.

Best for Content Sites

My blog is all content. If ever there will be additional dynamic content like comments, those will be additional to the content, like applying a decorator pattern. It makes more sense to serve static content from CDNs because that is what they have been designed for. It provides for better performance, higer security, and cheaper scaling.

Static/Dynamic

You can serve dynamic content with the JAM stack. For example, because Gatsby is React, I can have some components rendered on the server, and some on the client; the latter can be dynamic.

Stack Choices

There are many alternatives to the choices I have made for my blog.

Gatsby / NextJS

Instead of Gatsby, you could use Next JS. It is similarly based on React, but it is probably a better choice for Enterprises because it defaults to 'enterprise' features such as TypeScript support. Gatsby was a better choice for me because I needed to get to writing, instead of developing a product. As an aside, this is what solving for need means as per the Product Mindset.

GraphQL / REST

GraphQL is ideal for data discovery, and using it at build time to query the filesystem or other GraphQL APIs does not break HTTP semantics. However, using GraphQL from the browser will break HTTP semantics (every request will be a POST). If you need to care of the HTTP semantics in your application, then you can't use GraphQL (at least in the places where the semantics matter). Then there's a need for making sure all of your APIs support GraphQL. If one or more of these APIs are external, then you need to create an adapter API. Technically, any API will work, so REST is a viable alternative to this additional complexity.

Server Side Generators (SSGs)

JavaScript is by far not the only choice for SSGs. Neither is ReactJS a mandatory component of the stack. ReactJs can be replaced by VueJs for instance. Apart from JavaScript, there are SSGs in Ruby, Go, Python, Rust, Swift, C#, PHP and more. You can see a list here.

Source Control

I have used GitLab for source control, because when I created the blog, GitHub didn't have free private accounts. GitLab is an excellent choice for source control. I have used the self hosted version for many years with multiple teams working on different projects without a single hitch. If I had to make this choice today, I would have probably chosen GitHub because it is good enough, but if I knew how well GitLab integrates with continuous deployment, I would have chosen GitLab.

Continuos Deployment

I chose Netlify(https://www.netlify.com/) because it is a single platform for everything I needed - continuous deployment, domain name management and content distribution. This choice was influenced by the positive reviews of colleagues who are professional developers. Another common architecture choice is to deploy to an AWS S3 bucket, and manage the content distribution using AWS infrastructure. There are more options listed here.

Headless CMS

An interesting fallout of the JAM stack are 'headless' content management systems. Traditional CMS have followed a monolithic architecture, so they shipped with every feature that different stakeholders needed to do their bit for content creation and publication. It is really hard to do justice to all stakeholders with a single system, which is why the best of CMS would elicit complains from one or more stakeholders. As a former professional programmer, I was scared of working in 'CMS projects', because it meant hours of unending drudgery. Even today, as an Engineering leader, when I have to oversee CMS teams, I pray people won't quit on my face.

Headless CMS might be able to buck the trend.

They separate the different parts of the content creation and publication process. This allows developers to focus on one product for one stakeholder. This allows for faster turnaround time, better engineering, and higher user satisfaction. A Headless CMS system can build the content site from multiple different sources - a traditional CMS, an API, the sky is the limit; and each of those sources can be built their own way. The content authoring product need not worry about injection attacks because the content is never published through the content authoring product. The content presenter products do not have to fret about inconsistent look and feel of different content sources, and neither do they have to worry about talking to an inappropriate backend API.

Headless Commerce

An even more interesting fallout is the rise of headless e-commerce systems. Between 2005-2011, there was an explosion of PHP and Ruby products for e-commerce, and some of them are still popular, but they suffer from the same problems as traditional CMS. Actually, traditional CMS and e-commerce products suffer from typical COTS product integration problems - it is typical for COTS products to be modified to serve the business; when the limits of extensibility are reached, the product needs to be updated in ways that makes it impossible to upgrade to newer releases.

On the other hand, the elements of the e-commerce platform - sales, inventory, marketing, and shipping are stable. Each of these elements can be exposed as APIs, and this segregation would prevent the whole thing from becoming a big ball of mud. One can build mutliple frontends from this platform, and micro frontends are exciting. A business could create a micro-frontend for a new product line they are testing the market with; they could introduce a special look and feel (perhaps targeting a different audience?), all of which is built on a stable platform that is hosting the current product line.

It would be interesting however to see how these systems handle transactions, reporting, and analysis (such as fraud analysis). I think the platform will have to introduce some level of logical coupling between the different APIs, which the front ends may have to understand and use the platform accordingly. This may make the platform a slightly leaky abstraction, but still not violate the principle of least surprise.

Future

The rise of microservices and everything that it needs to be successful (the meplex), is moving all COTS products towards headless-fu. Headless CRM?