Headless CMS (Content Management System) architecture is a flexible development strategy for applications that is rapidly growing in today’s industry practices. Utilizing a headless CMS architecture allows an application to deliver content authored from a single interface to multiple delivery channels. Content is processed through an API (Application Programming Interface) and distributed to multiple channels or “heads,” by means of a central service, or the “body.” One of the concerns many organizations have about pursuing headless development is that producing content for multiple channels means having a team skilled in multiple areas. However, with a thoughtful approach, this can be a powerful opportunity for an organization’s engineering team.
The code base for a headless CMS is complex, more so than a traditional, monolithic solution. While it would be ideal to have a development team consisting of people with existing, overlapping skills in all of the pieces the headless CMS project will touch, the reality is typically quite different. Rather than viewing this as an obstacle, however, the broad scope of headless CMS projects offer an opportunity for growth in an environment of siloed development. Because a headless CMS application often houses several communicating services, it is absolutely necessary for the entire team to be in sync with where certain data lives, how content is structured, and how each delivery point communicates with other delivery channels and/or the central service. To accomplish this, it is crucial to intentionally build a well-thought-out, cross-functional headless CMS team that will naturally tear down the existing silos between team members who would otherwise work on only a specific, small portion of the application. The team can then learn areas outside of their comfort zone and ensure the development team remains in sync, all while delivering a valuable product to a customer.
Architecture of the Application
Planning Phases
Steps to building a strong cross-functional team begin early. During the planning phase for a headless project, if possible, ensure that the entire development team is involved in designing the architecture and selecting the technology stack for development. This will give engineers an opportunity to ask questions and explore learning materials regarding topics outside of their area(s) of expertise. Adding planning time into early sprints to invest in the growth of the technical team will pay off later in the development lifecycle. Beyond simply improving future work on the current project, expanding the abilities of the team now naturally leads to a larger bench of engineers who are experienced in the industry-wide practice of headless CMS development. It will also foster increased trust from both clients and the development team to have an entire team of developers fluent in the entire technology stack of an application. This allows for greater flexibility within both the space of a client’s availability and allotted work within a sprint.
Building the Codebase
Within the later phases of planning, consider the importance of structure and documentation within the API(s) that extend the functionality of the central microservice and deliver content. Building in the time to create solid documentation is a clear winner, both from the point of view of helping “future you” recall how a system works but also by making it dramatically easier for a teammate to pick up work in a new area and quickly get up to speed. Again, this expands the bench of engineers that are able to work in a traditionally siloed area, increasing productivity and mitigating the worry of technical debt. Engineers who are heavily involved in planning will feel more comfortable contributing code when development starts since they will be familiar with the architectural goals of the application. Because a Headless CMS is built with the ideal state able to implement limitless supported devices, building a codebase to house structured, flexible content, and clean points of communication results in a maintainable application and a well-prepared group of engineers. This also reinforces best practices of multiple languages/technologies during application development. As a result, engineers will better understand how to contribute scalable, well-commented code without the need for upskilling later on in the development process.
Development Processes
Team Code Reviews
In many aspects, code reviews within the agile development process of a Headless CMS remain the same. However, to integrate the continuing theme of team cross-functionality, it is important to include the entire development team in the code review process. As multiple features are being added to the application in a sprint, it is crucial to ensure each team member maintains their understanding of the codebase. When reviewing code, keep in mind the structure of the application. Consider how the content should be structured in delivery and storage. Furthermore, keep in mind that the structure of said content may also be transformed upon delivery through APIs. In this way, it is most efficient to have the entire development team involved with all reviews of delivered code, not just those who have expertise in that area of development. With good communication and team synchronization during the process of review, there will be less time needed for upskilling. This allows all involved engineers to add features without the necessity to take time reviewing content delivery or general points of communication between services housed in the Headless CMS application.
Consider having synchronous code reviews when code is added that will affect or extend the communication between APIs or any of the APIs with the central microservice. At the very least, make sure all developers have a chance to review all contributions made to the application as a whole to mitigate the scope creep caused by avoidable technical debt from upskilling later on.
Version Control Workflows
Another crucial aspect of Headless CMS development is the Git Workflow the application follows during a sprint cadence and production releases. It is surprisingly easy for a team’s Git Flow to fall out of sync in the midst of building features and making changes, especially when tasked with engineering such a large application. It is crucial for the entire team to understand what format their feature, bugfix, or hotfix branches must follow and where they should be branched from. This is especially important in the scope of building a Headless CMS application, considering all the possible points of failure between points of communication within the technology stack, channels of content delivery, and proper structure of stored data. If a team’s workflow falls out of sync, the possibility for portions of the application to fall behind or creep ahead increases. Accordingly, the imbalance of incurred technical debt may alter the development timeline of the application as a whole.
In Summary
To ensure the most efficient delivery of a headless CMS application, it is absolutely crucial to break down the silos of a development team throughout both the planning and development processes of a large application. Investing in the growth of developers and keeping a strong focus of synchronization regarding the whole product mitigates numerous risks of the development timeline of a headless CMS application. With the proper approach and correct mindset to leverage the opportunities of growth presented by this new development practice, a maintainable product can be delivered in the most efficient manner. Simultaneously, the development team involved with building the product will achieve growth and more opportunities to learn contemporary practices in the space of application development through hands-on practice.