Written by Fortnight web & mobile expert and superfan, Adam Roberts
After years of developing websites, I now feel the best approach is headless CMS and I want to tell you why. Before joining Fortnight, I had been learning to React for less than a year. I had been developing websites the traditional way for a good 18 years with HTML, SASS, JavaScript/jQuery, PHP and more often than not, with a CMS called WordPress. Everyone’s heard of that right?
I made the switch over to React because of several reasons.
React is a JavaScript library created by Facebook, that builds user interfaces for single-page applications where almost every interface element can be created as an individual component. It requires a minimal understanding of HTML and JavaScript to get going, but the more understanding you have of the fundamentals of websites with HTML, CSS and/or SASS, then you’ll be off to a good start. Any javascript experience is a big helper.
You can also write React (React Native) to develop apps for Android and iOS. Although it’s not the exact same code as opposed to the web, the knowledge is very transferrable.
My personal and professional experience with WordPress, creating custom websites for clients in nearly every industry spans to nearly 15 years. So I would like to believe I have an extremely good background to see the differences from then to now.
WordPress in itself is great. You have the core of the system which is open source and gets updated all the time. It has a theming system so you can create an installable theme which completely changes the look & feel as well as the functionality of the website. Each theme is built with a mixture of HTML, CSS, JavaScript and PHP.
But there’s also a plugin system where anyone on earth can write a plugin that provides certain functionality that you can quickly install and start using.
The huge caveat to this is that you can’t afford to just willy-nilly install the updates when they become available. You have to run a separate version either locally on your machine or on a development server, to run the updates and test it to make sure nothing on your website breaks. This can take too many hours to complete. And if you don’t update anything for a good amount of time, they become more and more vulnerable to malicious attacks, which then makes things more difficult to recover. Of course, there are certain things you can do to try and prevent attacks, both server-side and on the website itself, but it’s something you have to continue to maintain.
Probably the best plugin to ever hit WordPress was Advanced Custom Fields (ACF). It would allow developers to extend the editability of the themes and provide functionality that would have otherwise have been difficult to achieve. Baring in mind, I’m talking custom made themes because that’s all I ever did.
Although WordPress has proven to be great over the years, I have moved on for a better development experience for myself, but also to create far better products for clients and I have to thank the team at Fortnight for giving me the opportunity to continue down this path.
For more information on the comparison of Gatsby and WordPress, check it out here.
So let’s get in to React and see how we do things now.
The way I see it is we have 2 choices. We can use a tool called Create-React-App which is great for web & mobile apps. Or we can use another tool called Gatsby, which is a static site generator to create blazing fast modern websites.
For any sort of website whether it’s a brochure, portfolio, campaign or even eCommerce, using Gatsby will always be my first choice. The performance you gain out-of-the-box is second to none and optimising later is quite easy to get a score of 100 across the board on lighthouse.
So how on earth does it all work?
Using Gatsby as the framework for the website, we write our components in React. Gatsby also comes with GraphQL, an internal tool to query API’s and serve the components you create with data.
Data can be internal or external. I always take the external approach.
So where does the data come from?
This is what we call a “Headless CMS”. A Content Management System that sits in the cloud, that is used to build the content and served out as an API. We then connect to the API and use GraphQL to create “queries”. A query contains the names of all the fields that we created in the CMS, which returns data we can use to populate all of our components.
When we run the command gatsby develop or gatsby build, it fetches the data, populates the components and builds the pages.
We use gatsby develop when developing locally. We use gatsby build when we want to test the production version of it, or we put this into a hosting provider like Netlify or Zeitnow where the command gets triggered when content or code is updated (continuous deployment). This creates a new build, then the live website is updated. There’s a little bit more to it than that, but that’s the basics of the modern stack.
From a CMS point of view, we’ve looked at Contentful, Prismic and DatoCMS. I’ve personally used WordPress as the CMS in this scenario as well since WordPress has it’s own REST API, but it is very unnecessary since you need somewhere to host the CMS as well as build all the functionality with PHP and serve it to the API. 9 times out of 10, that will be a waste of time and money.
Contentful and DatoCMS are very on-par with each other, there are pros and cons of course, but our favourite would be DatoCMS for it’s simplicity, great pricing structure and ease of use from both developer and client perspectives.
Now here’s the big punch to the guts for any WordPress lovers out there.
Because we’re using Gatsby to build a “static website”, there is no need for a server to host it, so it’s the most secure a website can be. In Gatsby’s words; all your content and assets are compiled ahead of time, so hackers can’t get into your database or your CMS — since there is no direct connection between the front-end and the CMS.
That’s right, your website and your CMS are completely decoupled so there’s literally no concerns needed for security.
In addition to using DatoCMS, we add all the fields and content areas we need for the website, also known as Content Modelling, and those fields are automatically available in the API. There are a few “plugins” we can use to add to the CMS to extend our editor and API, but there’s nothing for us to update or check for security issues on a continuous basis like you have to with WordPress.
Additionally, Gatsby also has plugins. Plugins for the developer that allow us to do certain things with your data. For example, the plugin called Gatsby Image, allows us to render your image assets you upload to your CMS in a few different ways. We can now allow clients or editors rather, to upload their image assets at any given size, we can add limitations if we need to, but then using Gatsby-Image, we can fetch an optimised version of that asset, so you don’t have to do all that groundwork like you used to. That’s just one small, a great example of the power of Gatsby and why we choose to use it.
It is possible to create a “static website” for an eCommerce shop, it was actually one of the first projects that I did at Fortnight. And here is where it gets really exciting.
Using the power of React / Gatsby, we don’t have to accept just one system to manage our content. It is possible to connect multiple CMS’s and serve out a content-rich, product-driven website.
In this example, I used Gatsby for the front-end, DatoCMS for content-rich pages. Then used Shopify for the product listing and detail pages as well as payment processing. For my first big development project, this was no small feat, but it went buttery smooth because of the ease of Gatsby / React. Unfortunately at the time, I wasn’t able to use Shopify as the CMS for the entire website since it lacks a lot of features in that area, for example, they only give you a simple WYSIWYG editor, which just isn’t enough.
But after several weeks of development and testing, it’s proven to be a great piece for the Fortnight portfolio. We’ll share a post in the future with more detail around that project.
Using React or any other modern development framework allows heightened scalability like no other. Like I mentioned before, everything is componentized. Each individual component can add or remove functionality to the application, sometimes without affecting everything else. Let’s take a closer look, example of global components;
Now let’s take something like a component for “Latest News” which isn’t necessarily ‘global’, but can be plugged in or taken away easily. If I’ve written this component well, all I would need to do is make sure I pass data into it from a page level, the component itself would take that data, map over it and then display the latest X number of news posts. Components are very pluggable and enjoyable for the developer. One other way to explain this is with modular content, this is the part I love the most… I think.
In DatoCMS, Prismic, Contentful, even WordPress… we can take a modular approach to create content within the CMS. Depending on the CMS functionality, in my experience, they allow you (the editor) to move blocks of content up and down the page. Here’s an example;
Each one of those items being moved around is a group of fields in the CMS. The fields (data) for each of those items is presented in the query at a page level. Then the fields for each group is passed into its own component. Each component has it’s own styling, it’s own logic, etc. Take one away, doesn’t affect the other.
When you move content like the above example and save/publish, this will trigger a build if you’ve got it set up correctly. But even if developing locally, for now, you can see the order of your components change in the browser.
This can be done at any moment in your apps lifetime. Comparing to WordPress, you need much more knowledge of the website as well as knowledge and experience in several code based languages, to achieve updates and it’s nasty/lengthy process to get there.
State is a very big thing in React. If you’re coming from a PHP background, think “sessions”. Still no idea? Let me explain…
Let’s take a menu as an example. On mobile, in the header, you have a Logo and Hamburger icon (menu button). When you click the menu button, it changes to a different icon. It may even have a panel slide out from the side and give you a list of options to choose from.
Now, remember, the menu button is its own component. The menu (panel) is its own component too. The way I manage state is in a separate file (menuState.js), which is used inside both components. Inside menuState.js we’re making a state of isOpen to false by default. When you click the button (menu button component) we toggle the isOpen state to true. If you click it again, it goes back to false. Inside the menu component, we import that menuState.js and look at what the isOpen is, is it true or false? If it’s true, we pass that information into the styles, which then toggles the visibility of that component.
The same for the button itself, we can pass the isOpen state into itself to trigger some CSS animation. Here’s a look at the menu button component.
import React from 'react';
import { menuState } from '@states/menu';
import { observer } from 'mobx-react';import {
MenuToggle,
TopLine,
BottomLine
} from './styles'; // I use styled-componentsclass MenuButton extends React.Component {
openMenu = () => {
menuState.isOpen = !menuState.isOpen; // Toggle the state
} render() {
const menuChecker = menuState.isOpen; return (
<react.fragment></react.fragment>
<menutoggle isopen="{menuChecker}" onclick="{this.openMenu}"></menutoggle>
<topline></topline>
<bottomline></bottomline>
)
}
}export default observer(MenuButton);
And here’s the menuState.js
import { observable } from 'mobx';export const menuState = observable({
isOpen: false;
)};
Now any component in the future that I need to trigger when the menu has been opened, I just need to pull in that menuState.js file and check the isOpen and use it in my props. This is just 1 way of managing state, but I would suggest using React Hooks where possible.
When different elements on your website or app have different “states” depending on, data, onClick methods or something else, React is beyond amazing.
Yes, I love React. I love Gatsby. I love the modern stack. I know I’ve only touched on a few small points as to why React / Gatsby is great and are the tools of choice for building new websites, there are plenty more reasons why. But the biggest take from it, especially with my experience when coming from the traditional development background, is that it doesn’t matter what you’re building or how you build it, as a developer you should choose the technology you’re comfortable with to achieve what it is you’re trying to achieve. Everything I’ve talked about is all the same in Angular and Vue. Everyone has their own tastes around this, but I’m delighted to have been able to embrace React as has opened so many possibilities and the end products themselves are amazing!
.png)
