The home of football in Singapore, our partner Singtel has the widest coverage of the most competitive football leagues around the world. It is only natural that one of their thrusts to engage the huge set of football fans in Singapore would be through a unique and compelling content platform that would amplify their media reach. This is what gave birth to Football Siao!
In the world of sports commentary, punditry is the norm. So when our content team approached us, part of the pitch was for their varied and highly opinionated roster of commentators to directly input their columns on any section of the site. As in an actual football match, commentaries would come flooding in from all corners, so the platform had to be prepared. “All we’d do is to create a new module of writers and link it to existing modules,” they proposed, “instead of changing everywhere to make things work.”
Our solution was to design the website using a Headless CMS approach.
What is a headless architecture?
A quick lecture on web architecture: Headless CMS, short for headless content management system, is a back-end only content management system built from scratch as a repository for content for display on any device. Literally, it harks to the dismemberment of the “head” from the “body.” From its official definition, the front-end component of a Headless CMS is separated from the actual serving of the website or app. Unlike legacy systems like WordPress, Drupal, or Joomla, which are hosted and built together every time it’s served, Headless CMS differs because it is not attached to the frontend, and the content can be viewed on any platform.
Why we went for Headless CMS
1. Because of its flexibility
Headless CMS delivers content through an application program interface or API and is not coupled with a front-end, thus this flexibility allows us to do an enormous number of things even within a limited timeframe.
Similar to a page with all posts arranged into a category and some subcategories, a platform on Headless CMS holds content so it does not disturb the front-end. This makes it easier and quicker to make changes, considering that every day, any new sponsor and ad placer could come in. The volume of data won’t interfere with the introduction of new data.
2. It fits the content
Apart from the development, the content is also light. It not only is time-sensitive, it also only contains mostly just text (not much data) without the plethora of meta descriptions that other pages normally contain. All we needed is a medium to store the content and send it to the front-end with no frills.
3. It is way, way cheaper
We are expecting to have at least 1 million traffic monthly, and frankly, we are a small tech team working on a at least a couple of projects together. Building architecture with a cluster of the database, cluster of logic, etc. increases infrastructure cost, and maintenance is a headache.
So what we did was we used APIs to fetch data to our front-end. In one call, this takes data from each article, creates from it an HTML page, saves it, then caches it. This results in a reduction in the server load, because in old-fashioned CMS-based website, a user trying to open a web page means—take a deep breath—that a request goes to server, server sends the same request to application logic, application logic sends the same request as a query to the database to find where the data is, the data is sent to application logic, and after application logic renders the data in the style and HTML it has been coded, only then will the delivery arrive to the user.
Now imagine 10,000 users online at any given time, which means instead of just one request, there are 10,000 requests going to the database, entailing so many actions entertain all these users. Hence the big servers, infrastructure, teams, etc. In other words, it requires a BIG INVESTMENT OF MONEY.
On the other hand, on a Headless CMS, when 10,000 users go online all at the same time to access any part of the website, the server does not repeat all the steps because it already has the results stored. So there is no application logic call, no query to the database, etc. It simply delivers the HTML to the user and hence it results in 90% reduction in server load. (Thus, this leaves us to enjoy our whiskey and sleep!) Not to mention, this 90% reduction also has an impact on the cost of maintaining a larger team and larger infrastructure. Sounds nice now, right? But you might ask, how about the content team?
How the content team enjoys the flexibility of Headless CMS
1. Ease of use
We have a simple menu in the back-end, with the titles of each section as they appear on the website. So, if a columnist is publishing an article for, say, the Latest News section, he or she would know where to go and put it.
We are showing them only those fields that they need to put input in to make that article live, no extra fields to confuse them, in the sequence they prefer.
The content team had their own idea of doing posts in their own style. They sat with creative team and described to them which styles and layouts would best convey their ideas. So what we did was gave them those tools in the form of various buttons in the CMS itself. With full flexibility, they can upload an image, add the image credits and captions, add a straight line between chunks of text, a subscription box in between articles, etc. Since it was not a tightly coupled CMS, we built our interface exactly the way our content team likes it!
Issues in using Headless CMS
As every good thing still comes at a cost, there are cons to using Headless CMS as well. For now, it wasn’t cost as in financial cost, but a few issues:
1. Not error-free
Since we were rendering or in simple terms creating HTML for everything in one go, what happens when a writer makes a mistake and wants to go back and make a change? Will the system get the whole data again and create the HTML for whole website again? That could mean downtime on website and can be a pain as well as creating frontend build can be heavy on the server. Well, usually in SSR or Server-side Rendering Systems, this is how it works, but thankfully we found an amazing SSR called React-Static, which allows incremental builds, in which the part that is updated gets updated and hence it has a solution to one of the cons that we’ve in headless CMS and SSR combination.
2. Maintaining two different components
With two different components of the site, one being the front-end and the other, the back-end, the site will only work if it is managed properly and very carefully. Gratefully, we haven’t encountered errors yet..
3. No preview
With two separate components, which are only connected by a webhook to send notifications, how do we show our content team how their article will look like once live? For this, we created a simple react app which had a similar structure to our react static layouts and fetched data using APIs to show in preview to the content team. It uses common CSS and templates so everything that is live is synched with the preview.
At the end of the day, it is the user who can attest to the functionality of the project.
Using a traditional CMS, the content team will have to write an article, share it with the creative team (who will resize images to fit into CMS), get it back, plug it all into the CMS, and then bug us, the devs, to fix things if they want something else or something fancy, and then only after all these delays will things (finally) go live.
But with the Headless CMS, the content team can just think, write, then click publish! Best part is the article goes live with all the bells and whistles—without much intervention from the developers.
Sure, as in everything else, there are cons that accompany the pros, but in the case of Football Siao!, this is how we made the content team our friends, while empowering them not to depend so much on us.
Our team of highly experienced strategists, creatives, digital marketing specialists and technophiles can help you craft a content plan. Reach us by email at firstname.lastname@example.org or fill in our enquiry form to discuss. You can also take a look at our list of services.