Why And How We Redeveloped Our Website Using A Headless Stack
March 02, 2021 / Bryan Reynolds
Reading Time: 10 minutes
As the internet becomes more complex, so do the users' needs. They expect quick, always-on on and easy-to-use web platforms. For businesses that use their website to educate and attract new customers, there are generally multiple pages, functions, and user experience features that must be factored in when a web platform is created.
This is part 1 of our 2 part series on headless development:
- Why, and How We Redeveloped Our Website Using a Headless Stack
- Why We Went With Craft CMS for Our Backend Content Management System
With the internet becoming more complex comes great improvement in life quality. So as users’ needs and wants continue to change, the internet is ever-growing, stay ahead of the game by keeping up with the latest web development trends.
We have big growth goals, and part of our strategy is using our website to attract and convert new customers. The gap between what was, and what needs to be from a technology standpoint is constantly increasing - and there is only so much monolithic architecture can do.
What is monolithic architecture?
The term ‘monolithic’ is used to describe a system or architecture where all parts together form one deployment unit. Monolithic architecture is both interconnected and independent, rather than loosely paired.
Monolithic architecture is when the front end of the code (i.e., html5, CSS, and JS) is coupled with the code’s back end (i.e., PHP, MySQL). These systems are generally easier to deploy at the start as they have been the standard for web development for as long as the web has been around.
However, they do have clunky codebases and for builds that rely on multiple services, code and databases. If you want to change a function in one area of a website, you risk rewriting other areas of the site for the code to remain consistent and continue working.
If you want to send information to a mobile application, a web application, and a CRM system at the same time, you have to run everything through one single system. Everything is mashed together on one (sometimes more) server(s), and the code functions as a whole - creating the risk of bottlenecks when it comes time to scale.
Pros of monolithic architecture:
Very well documented - has been the standard for years.
A quick way to get an application up and running.
Easy to find developers due to age.
Will eventually be an outdated way of development.
Risk of bottlenecks and sluggish code due to all code being served at once.
Harder to make micro changes to code without affecting the rest of the application.
Very hard to tie multiple web services together as everything must go through a single system.
Less secure due to the backend services being exposed to users when content is served.
What is headless architecture?
Don’t worry; it is not as medieval as it sounds. If monolithic is the slow, clunky and older family member, headless is the cooler, faster, more agile younger sibling who is quickly starting to outshine their dated counterpart.
Headless architecture has a de-coupled structure. The aim of the headless is to use technology in microservices, allowing each service to do one function, and do it very well. A prime use case of headless architecture is Facebook (they actually invented ReactJS, one of the most common front-end technologies to pair with headless deployments). Facebook uses ReactJS for themselves and maintains it, offering optimized and new versions for developers.
They must send information to multiple devices for the same user, simultaneously, without bottlenecks. Their front-end technology (ReactJS) uses an API to query their back-end technology (PHP) for information from their server (SQL), the data is then passed back to the frontend at light speed. The overall load on the technology stack is minimized as the information is rendered on an “as needed” basis, not all at once in a mash of front-end code, database queries, PHP functions, and content.
Pros of headless:
At the core, is an agile framework
Very secure due to backend removed from the users reach
Cons of headless:
Harder to find developers due to the age of the framework.
Documentation is harder to come across due to the age of the framework.
As great as headless is, it’s still harder to code in.
We believe that the reason headless architectures are harder to code in is due to the lack of documentation. So guess what we are doing? Writing documentation on how we used Craft CMS, ReactJS, and NextJS to roll out a lightning-fast website that will assist us in scaling our website content far and wide.
In part 2 we will cover why we went with Craft CMS for our backend content management system.