A cofounder of the Strapi open source project--which has 450 external contributors and users that include IBM, NASA, Walmart--reveals how the headless CMS is impacting front-end software development.
As important as it is to modernize back-end infrastructure, far more developers will engage with front-end development. As Kelsey Hightower rightly reasons, though, "There's a ton of effort attempting to 'modernize' applications at the infrastructure layer, but without equal investment at the application layer, think frameworks and application servers, we're only solving half the problem." To enable that front-end development, key innovations have been helpful, among them the rise of the headless content management system (CMS), which decouples front-end development from the back-end CMS.
In a world where content is as likely to show up in a smartphone app or IoT device as a web page, and where developers have been spoiled by rich front-end frameworks like React, developers don't want to be locked into an all-in-one CMS that ends up doing nothing particularly well because it tries to do everything. Instead, argued Pierre Burgy, CEO and cofounder of Strapi, the company behind the eponymous open source project, developers want a headless CMS. There are several reasons for this.
SEE: How to build a successful developer career (free PDF) (TechRepublic)
Square peg, round hole
People have been building CMSs for eons, with scads available across a variety of languages. But that doesn't mean developers like using these traditional CMSs, said Burgy in an interview, because a CMS constrains developers more than it enables them. Yes, it helps them manage content and push it to websites, document management systems (like SharePoint), and more--but, it also tends to lock the developer into using their preferred front-end system.
"Most of the time developers don't really like this," said Burgy, "because the creators of the CMS tend to be focused on the content management interface, not the front-end experience." In a traditional CMS, all of the components are inside the CMS: Front end, authentication, content, everything.
It's a win for all.
APIs to rule them all
One reason that headless CMSs like Strapi have taken off is because they enable developers to build with APIs, not calcified front-end systems. As mentioned, the traditional CMS is an all-in-one solution that removed developer choice, but in a JAMstack world, each of the individual components is split. As Burgy explained, there is a front end somewhere, there is the front-end hosting somewhere, there is a CMS somewhere, there is a service provider somewhere, there is maybe an authentication system, a payment processor, etc., but these are all accessed via APIs. "APIs in the JAMstack are really the glue between all of these different parts," described Burgy.
This API-driven JAMstack approach, said Burgy, results in better customer experience:
JAMstack is cool for developers, which ultimately is a very good thing for the end users. For developers it means they can use modern technology, and it gives them much more flexibility when they develop, because they don't have all of the constraints from the CMS. This added flexibility for developers means they can develop faster, because they don't rely and don't depend on the CMS. From an end-user perspective, a website made with JAMstack yields much better performance which, in turn, increases conversion rates, especially on ecommerce websites.
As developers look for a headless CMS to pair with their preferred front-end framework, Burgy argued that a full cloud approach (headless CMS as a service like Contentful) isn't ideal because larger companies want to self-host (more than 50% of the market, according to Burgy) so they can maintain data privacy and heavily customize their CMS. When Burgy and team founded Strapi in 2015, he said it was a "no brainer" to make it open source so companies could host it themselves and tweak it to suit their individual needs. Two million downloads later, Strapi has 450 external contributors and users that include IBM, NASA, and Walmart.
The approach seems to be working.
Disclosure: I work for AWS, but the views herein are mine and don't reflect those of my employer.
- GitHub: A cheat sheet (TechRepublic)
- Telephone interview cheat sheet: Software developer (TechRepublic Premium)
Microsoft Office vs Google Docs Suite vs LibreOffice (Download.com)
Programming languages and developer career resources (TechRepublic on Flipboard)