There has come a time in every company when applications had developed to such an extent that a common content management solution is needed. It’s crucial to choose a proper one, which fits current requirements, but also will be ready for future growth.
In our history, there were plenty of situations where CMS were migrated to a new one, for different reasons such as:
Nowadays most businesses based on the content & data which are the real value. Content Management Systems as the name suggest 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, both this on a small scale and the one with an enterprise complexity 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 changes really rapidly, 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 to 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 scale resources up or down depending on actual usage, as well 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 respond to rapidly changing resource requirements.
To fulfil business requirements, content management systems need to be very customizable. We choose Strapi headless cms due to many factors, one of them is the possibility to integrate 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.
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 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.
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.
Strapi is ready to use the product, however, there is an option to overwrite every single fragment of application, including builtin controllers and services for created content types, but also core functionalities such as authentication or admin panel customization.
Builtin 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
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, everyone could focus on developing new features using watch mode.
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 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.
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.
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 to create the same resource, trigger the same logic for several different recipients, without affecting the others existing. What 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 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 who 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.
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 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.
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.
Overwriting a Strapi core is done by extending Strapi built-in plugins such as strapi-plugin-content-manager, 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.
