The LibraryOn project aims to be the digital front door for the UK’s library system, connecting users to 3,601 libraries across 209 authorities. For a project of this scale, managing content efficiently is crucial, and that’s where Strapi—a flexible, composable headless CMS—comes in. Strapi’s dynamic capabilities offer immense potential to streamline content management, empower editors, and ensure a seamless publishing workflow. However, flexibility alone doesn’t guarantee success. As with any technology or infrastructure choice, the true potential of a platform is unlocked only through correct implementation—in this case, the most effective work simplified the content structure, empowered content creators, and provided a scalable foundation for growth.
When I first encountered the LibraryOn project, Strapi was underperforming—not because of its limitations, but because of how it had been implemented. Multiple single content types were mapped to different Next.js pages, creating redundancy and confusion. There were 19 collection endpoints managing content like articles and subpages. Even worse, some collections were dedicated to single-use instances, unnecessarily complicating the system. For example, three separate collections managed only two articles each, requiring developers to make even the smallest content changes. This setup hindered the entire project, defeating the very purpose of Strapi, which is to empower content editors with flexibility and reduce dependence on developers.
The Strapi implementation was not leveraging its dynamic zones or flexible API structure, which are designed to give content editors control and autonomy. Without these key elements, every update had to go through the development team, creating bottlenecks and stifling the creative workflow. Correct implementation of Strapi isn’t just about using its features—it’s about creating a content architecture that scales with the project and evolves with the needs of the team.
This case study outlines the process of refactoring Strapi’s setup to simplify the API, eliminate redundancy, and provide content editors with the tools they needed to manage the platform independently—all while rebuilding the frontend to align with the improved structure.
When I took on the LibraryOn project, I found a Strapi setup that wasn’t optimized for the team’s needs. Content management wasn’t as flexible as it should be. There were multiple single content types, all mapping to multiple Next.js pages, and 19 collection endpoints for various content like articles, subpages, and more. Some collections were unnecessary; for instance, we had three single-type instances managing three separate collections of articles, despite only two articles existing per collection.
This structure meant that even the smallest content change required the content editors to go through the development team first. This not only slowed the process but also defeated the purpose of using a CMS like Strapi, which is meant to offer content editors autonomy and flexibility.
Content-Types | Location on the website | Frontend |
---|---|---|
Article Author | Article Page, Author Bio Section | N/A |
Awarded Projects | Grants Page, Awards Section | grants.js |
Books and More Articles | Story page - child pages | books-and-more.js |
Button Row w/Heading | Logo Guidance | N/A |
Conference Session | Press Play page | pressplay.js |
FAQ | Homepage, FAQ Section | index.js |
Grants Application Docs List | Grants Page, Application Resources Section | grants.js |
Grants Pages | Grants Overview Page | grants.js |
Learning in Libraries Articles | Story page - child pages | learning-in-libraries.js |
Legal Page | Legal pages | legal/[slug].js |
Special Collection Story | Collections Page | special-collections/stories/[slug].js |
Story | Story pages | books-and-more/[slug].js learning-in-libraries/[slug].js learning-in-libraries/[slug].js |
Timeline | Special collection | special-collections/stories/[slug].js |
Topic | Unknown | N/A |
Your Community Articles | Community Page | your-community.js |
About | About Us Page | about.js |
Global | Main navigation | (Global) |
Grants | Grants page | grants/[slug].js |
Home | Homepage | index.js |
Legal Page Navigation | Legal navigation | legal/[slug].js |
Logo Guidance | Branding Page, Logo Usage Section | logo-guidance.js |
Press Play | Press Play page | pressplay.js |
Special Collections | Collections Page | special-collections/index.js |
Here is the original structure of content and next.js render layers. After the refactor thinking about the simplest way to output the same content from the CMS resulted in this:
Content-Types | Location on the website | Frontend |
---|---|---|
Home | Homepage | index.js |
Pages | All content pages | [...slug].js |
Special Collection | Special Collections | special-collection/[slug].js |
| | |
| | |
Authority | Authority Pages / Map | /libraries/authority/[slug].js |
Library | Library Pages / Map | /libraries/authority/library/[slug].js |
This new structure allowed a much cleaner codebase and backend configuration and it also introduced Authority and Library collection types allowing the project to shift away from the separate Mongo databases and deprecate the code which ingested this data.
My approach was simple: reduce complexity and unleash the full potential of Strapi. I refactored the entire structure by consolidating all single types and collection types into two streamlined content types:
Dynamic Zones in Strapi allow content editors to manage and reorder different components on a page without developer intervention. By implementing Dynamic Zones, we gave the content editors full control over the layout and content across all the pages, empowering them to manage the website with ease.
This shift resulted in a cleaner API output while maintaining the same content but in a more composable and flexible manner. More importantly, it returned the power to the content team, enabling them to create, edit, and reorder content dynamically, without waiting for development input.
To match the backend refactor, we rewrote the entire frontend to work seamlessly with the updated Strapi structure. We implemented a dynamic component renderer function to handle content rendering based on the layout set by the content editors in Strapi.
This approach used atomic design principles, where components were broken down into smaller, reusable elements. We integrated Storybook to document the CMS functionality and for easy UI testing and design review. This allowed us to create a collaborative environment for both designers and developers and provided comprehensive documentation for content editors directly within Storybook.
Once everything was in Strapi the project could make use of some more functionality in the backend and the frontend, using the power of Strapi’s population and field selection we could improve performance and offer end users enhanced functionality.
The projects map page, a listing of all libraries in the UK went from looking like this:
To a more enhanced feature, with autocomplete powered by the Strapi plugin Mellisearch and a UI fully populated with content that end users can search, filter and refine easily.
The project also presented an opportunity to simplify our infrastructure. Previously, the Next.js site interacted with three MongoDB clusters for rendering library data. These clusters contained data for the UK libraries, library management systems (LMS), and library authorities.
As part of the refactor, we built a custom Strapi plugin to import and manage library data directly within the Strapi CMS. This eliminated the need for separate MongoDB clusters and allowed content editors to easily manage and update data for all UK libraries (including the LMS and library authorities) from within Strapi’s user-friendly interface.
By centralizing all data within Strapi, content editors now have direct control over updating the content, reducing the overhead and potential errors from the previous multi-system setup.
The results of this refactor were immediate and powerful:
This refactor serves as a perfect example of how proper implementation of Strapi can unlock its full potential, enabling content editors to thrive and removing unnecessary development bottlenecks. By rethinking how the CMS was structured and integrating dynamic zones, we transformed LibraryOn from a complex, developer-centric project into a content-driven platform that truly empowers its editors.
For any project looking to optimize their content management workflow, especially when using Strapi, this case study shows that focusing on simplicity, flexibility, and the editor experience is key to success. Strapi is incredibly powerful when built correctly, and with the right approach, it can give your content editors the superpowers they need.