Monolithic to Jamstack

Alex Bennett 28 August 2021

Modern web development is diverse in its technology and even more diverse in the application of those technologies. Traditionally people have a preference for stacks geared around specific languages. For PHP it’s defined as a LAMPstack, that being Linux, Apache, MySQL, and PHP. MEANstack showed up a little later and is defined as MongoDB, Express.js, AngularJS, and Node.js. Or there is NETstack, which isn’t a catchy acronym for anything but is based on .net as its language. However, the newest stack on the block is perhaps the most versatile of the bunch, and in this post and further posts, I’ll be talking about my experiences with JAMstack, which is defined as JavaScript, APIs, and markup.

As businesses evolve to become more agile and stay relevant the technology we offer has had to evolve to support them. In my career I’ve had the opportunity to work on pretty much every CMS out there, some are more opinionated than others about how content should be structured and how that content then needs to be displayed in the render layer. The benefit of JAMstack gives flexibility with the content editor of your choosing and due to it being decoupled from the render layer, you can present this content in whatever medium suits you best.

The stack itself allows for a reduced cost in hosting, faster to develop for, increased security, and improved scalability. The render layer is down to the development team’s preference, there is no right answer. It’s what the team is most comfortable with or most experienced with. The content management system comes down to the needs of the project I’ve written a breakdown on headless content management as a concept for the 43ClicksNorth blog, you can read that here.

Compared to traditional monolithic setups JAMstack is lightweight, this improves user performance, and an improved user experience when it comes to performance ranks you higher in SEO since the May 2021 update to the Google algorithm. Monolithic setups such as Drupal or WordPress come with a lot of bloat on the client-side which adds a cost to performance metrics, they also come with a lot of admin UI noise. I’m sure you’ve experienced clients accidentally breaking their sites on platforms that have a bunch of buttons in the backend a content editor has no business pressing, and oftentimes developers on these platforms fail to properly secure these dashboards for their users with the appropriate permission layers. The traditional CMS also comes with specific knowledge requirements, whether you’re building for a LAMPstack CMS or something .net you often need developers with specific experiences or skillsets, the most expensive of which to recruit for are often on the NETstack side.

Now I have nothing against these other stacks, for the majority of my career I’ve worked with them, Umbraco being the most recent CMS I’ve built sites in, however, I felt at 43ClicksNorth we should adopt the cutting edge of modern development for the web. This should allow me to focus my recruitment efforts on people with front-end learning skillsets.

A good frontend developer should have extensive experience working with JavaScript and quite possibly experience working with a JavaScript framework such as Angular, React, or Vue. This skill set allows the developer to focus on functionality and layout traditionally on the client-side, but the emergence of server-side rendered applications with the dawn of node allows the skillset of JavaScript developers to break through the traditional dichotomy. I could write extensively with opinions of the merging of frontend and backend dichotomies but for now, to keep it short, the skillset of JavaScript overlaps greatly to really be full-stack these days. With this in mind and my personal preference for development, JAMstack will be well suited to my current workflow and aspirational goals for future projects.

Where to start with JAMstack

The first thing you’re going to want to figure out is where you’re serving content from. There are numerous options for this, I recommend doing your own research to find a product or service that best suits your needs or your client’s needs.

I’ve spent the last two weeks experimenting with various headless content management systems, from SaaS products to self-hosted. Though there is a variety in functionality, admin layout, and concepts I’ve finally settled on for an in-depth R&D project on the eve of using this stack on a new greenfield project at 43ClicksNorth. Strapi seems to offer the suite of functionality I was looking for in a headless content management system, with flexibility in content editing, a reasonable content editor experience, authentication, and user groups.

By default Strapi is set up with an SQLite database, however just to challenge myself and learn something new, I’m going to be switching it to use MongoDB. I’ll follow up with a blog post about this setup later, with other posts explaining other aspects of my chosen JAMstack.

For the render layer, I’ve decided to keep to my current experience and use Vue, specifically, Nuxt.js as I want server-side rendering for my projects and Nuxt is really easy to work with. As a bonus over frameworks like React (which in my opinion has become quite monolithic itself) or Angular, Vue has a much easier learning curve. This should allow for junior members of a team who might not be experienced or confident with frameworks to pick things up quickly.

To communicate with the API from Strapi, I’m using GraphQL via Apollo, there is a nice to use and well-documented module for Nuxt to help with this here.

From what I’ve set up so far the developer experience is friendly and the documentation is well written and informative, for both initial setup through to rendering content. I’ll publish some additional posts for the stack I’m using and maybe it’ll benefit someone else going down this route, as it’s not been without some hurdles, especially their Dynamic Zones with GraphQL.

Overall I’m enjoying the experience of developing with Strapi and my other chosen technologies, I’m looking forward to seeing the final product and introducing some quality of life aspects like Storybook and then dockerizing the backend and frontend applications. Once I’m done I’m expecting it to be the new gold standard for how we develop at 43ClicksNorth, and I look forward to onboarding new developers to the process and refining it over the coming months.


If you have an interesting opportunity or a project in need of a developer, please get in touch: