In our history, there were plenty of situations where CMS were migrated to a new one, for different reasons such as:
Hard to maintain
Not enough availability
Security reasons (most popular CMS are also the first target of cyber attacks)
Low scalability or no scalability at all
Many customizations which make version upgrades almost impossible
Poor quality of delivered plugins/extensions
Many different teams worked without specific guidelines or even project management which resulted in different approaches, code duplications, or sometimes different languages/frameworks used within one CMS
Lack of documentation or poor quality.
Nowadays most businesses are based on the content & data which are the real value. Content Management Systems as the name suggests were dedicated to managing content, however, most available CMS also provide a view layer for the final users. Such an approach seems to be a good solution but without a long-term vision. Headless Content Management Systems are the answer for rapidly evolving edge technologies thanks to their focus on the data structures delivery rather than combining data with a view.
Business, whether it's a small scale or a large enterprise, requires scalable solutions that are easy for long-term maintenance and extendable depending on the market specific as well as individual requirements. Time and technology change rapidly, and each business needs to follow trends to be a step ahead of competitors. Choosing a solution that implements the right concepts to power up marketing, identity, and comms across our company is significant.
Most of Content Management Systems deliver very strict model content editing where the authoring tool is responsible for the look and feel of the end-user application/website. Mostly in trivial and straightforward cases, it’s acceptable with some tradeoffs. Anyway, in a long-term perspective, maintenance and upgrading become really painful. Decoupling of the authoring and presentation layer is much more flexible and long-term. Fortunately, there is a subgroup of CMS that provides content in the headless model in which being visual agnostic is a core concept. The authoring tool injects data structures into the end user application which thanks to that, might be developed and maintained independently. On this basis, Headless CMS is treated as a Content Delivery Service / API.
Scalability is one of the most important concepts for multi-tenancy cms, ease of scaling resources up or down depending on actual usage, as well as the ability to add new tenants without any changes in code or system architecture.
Chosen solutions and technologies give us opportunities to add new CMS API consumers without any changes in cloud infrastructure.
We could divide our application into the database layer, and application. It is crucial to have a stateless web server to be able to run multiple server instances at the same time, the server itself doesn’t share any state between requests.
Fully managed databases from one of the Cloud providers give us High availability and scalability out of the box for a single database server up to 64vCores.
For web servers – scalability is guaranteed by Kubernetes which they run on. Kubernetes autoscaling enables to transparently responding to rapidly changing resource requirements.
To fulfill business requirements, content management systems need to be very customizable. We choose Strapi headless cms due to many factors, one of them being the possibility of integrating with very specific branding requirements, 3rd party single sign-on (SSO), or very restrictive security policy. In general, there is a possibility to develop every new feature as an additional plugin without touching the core of Strapi core or with minimal changes.
The clue was to select the right solution from the set of available. Strapi was one of the brightens on GitHub with more than 32k stars. That was one but not the crucial criterion of choice for Headless Content Management System (CMS) for the leading global retailer.
Faster content-delivery
Strapi core idea is to focus on models, and the rest is handled by its engine. Automatically created controllers & services (which could be freely customized), auto migration when the model has been changed, and the most important thing is that configuration of models schema is mapped from JSON configuration files. Such an approach allows storing all the configuration in the GitHub repository which makes the solutions independent from the database. That was one of our core requirements when deciding to use Strapi over the other CMS.
All above, allows the developers’ teams to focus more on business logic instead of the whole concept around migrations or creations of database schemas.
Configurable
The model could be created using many different fields like string, richtext, number, date, password, uuid, enum, relations, JSON, and many more, as well as application configurations including database, security, requests, response, or different mounting path for admin panel and API using environment variables.
Extendable
Strapi is ready to use the product, however, there is an option to overwrite every single fragment of the application, including built-in controllers and services for created content types, but also core functionalities such as authentication or admin panel customization.
Built-in security
Built-in authentication and RBAC but also Strapi is secure in the context of many popular vulnerabilities which could be customized using configurations: injections, csp, p3p, hsts, xframe, xss, cors
Developer friendly
For development we use docker-compose and run Database and application inside docker containers together with development mode makes it much easier to start working on a product for developers, no configuration is required, and everyone can focus on developing new features using watch mode.
More others
Performance
Lightweight/modular architecture – A big bonus is that all Strapi was designed to have modular, lightweight architecture, every single feature could be developed as a separate plugin.
What also decided about the success of Strapi – an open source nature, it was developed under an MIT license which is one of the most permissive licenses.
Written in JavaScript and published on NPM, which gives developers the opportunity to use packages from the biggest package manager.
Strapi is the most popular open-source Headless CMS written in JavaScript, with about 50 thousand weekly downloads on NPM. The team of Strapi continuously works on improving the product, adding new features and fixing bugs (day of making the Stats picture is Dec.12, 2020).
Additionally to the OS, with paid plans, Strapi enables Enterprise Premium Support and getting rid of limits enabled for Community Edition, which opens a lot of possibilities for the business.
All systems, from the smallest to the biggest ones require company & law specific security features to be applied. Most of the OS solutions that are widely used, got them all implemented already in place. Although there are a couple of them that should be aligned to the individual requirements what in result improves the security even more.
Custom & strict SSO integration
Most of the companies “outsource” their authentication and access control to the Single Sign-On providers like Facebook, Google, Microsoft, OpenId, and others.
Strapi delivers support for the top of them, but thanks to the architecture and concepts of Providers and Extensions, thanks to that support for a highly custom one is easy to provide. As well as customizing the authentication flow which might work strictly with client Active Directory Groups that can be mapped directly to the roles managed by built-in Strapi RBAC.
Joining the custom provider and client AD automation gives a really secure and fully automated mechanism for controlling the MCCD access accepted by the top techies in this world.
Policies
The built-in concept of API Security Policies is a huge advantage that lifts the security to the next level of abstraction. First, in the queue aside from the default JWT Authentication headers policy can be provided others like:
By default, Strapi gives complex Role Based Access Control to limit the visibility, features, and experience depending on the role. Although all the users are working in a single context and all the actions are within it. There is no possibility of creating the same resource, triggering the same logic for several different recipients, without affecting the others existing. It makes perfect sense for a single auditory.
Thanks to its extensible nature, it was possible to introduce the new, extra concept the solution implemented for global retailers which expect to coexist multiple distribution channels within a single strategic implementation. The virtual tenant context allows for minimizing the number of duplicated logic/components by sharing them between the channels. As well as minimize costs, thanks to the fact that everything might work on the same scalable infrastructure and don’t need to be client-dedicated.
The virtual tenancy is a special application layer that identifies from whom the query comes from and limits its access only to allowed resources. It is impossible to fetch and manage content and data restricted to the different tenants.
RBAC joint with Contexts
The virtual tenancy has been applied also to the administration panel by defining appropriate roles so that administrative users can see only the data intended for them. Using the built-in RBAC together with customer contexts allows one to freely define the role of access to individual resources and makes administration tasks smooth and transparent.
The solution designed in this way is extremely flexible and can be freely expanded depending on business needs.
Strapi modular architecture gives the chance to develop a single feature as an independent plugin/package which is more compliant with the single responsibility rule.
Domain-specific functionalities, components, and data models are developed within the Strapi instance itself
More generic plugins that could be used by a community are expanded/improved in VirtusLab public repositories
The smallest part of the whole application is small amendments in Strapi Core – changes are required due to very specific security reasons, authorizations, or branding rules that need to be fulfilled.
Open source spirit
The possibility to seamlessly develop new features gives us the opportunity to create new plugins and share them with the community, as a part of MCCD so far VirtusLab has published 8 packages on the public NPM registry and got a few more in plans for the upcoming year. As an open source, the community is improving & maintaining “bricks” of MCCD which eases work and gives the client business continuity of improvements and maintenance regardless of who in the future is going to take responsibility for the solution in the internal structures.
Implementing detached packages from Strapi Core gives more flexibility in the scope of libraries or even programming language. So, all the code is developed using TypeScript, which brings a lot more useful features than we might expect from the Core.
UI Navigation Navigation / menu builder feature with their possibility to control the audience and different output structure renderers like (flat, tree and RFR – ready for handling by Redux First Router)
Comments End-to-end comments features with their moderation panel, bad words filtering, abuse reporting and more.
Audit Log Monitoring administrative user actions and data changes with the possibility to revert unexpected changes.
Overwriting a Strapi core is done by extending Strapi built-in plugins such as strapi-plugin-content-manager, and strapi-plugin-user-permission, which is the bottleneck of the whole development process. That’s why it’s crucial to make as few changes as possible, and instead of modifying whole files, what can be achieved by creating own utils/packages and using them inside modified Strapi source code. That makes future maintenance and migration between core versions significantly smoother.
For example, to add new features in the existing code, the implementation of useCustomHook might be decoupled from an originally overwritten file to a separate util file or even a separate package.
The Multi Context Content Delivery built on top of Strapi CMS is a powerful and every market fitting solution that eases daily routine processes, content management, employee comms and much more. To be fully honest, there is no requirement in the content domain that can’t be implemented by extending MCCD to company needs.
Joint together with all-in scalability, performance, and technology stack enabled significant cost reduction in every scale business. Also not unimportant is the fact of finding the people that are going to develop further extensions and maintain the solution in a long-term perspective.
