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.
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 Strapi.io 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: