API-first is not just an empty promise, but something that the programmers at cmsWorks have incorporated into the DNA of the entire system from the very beginning. API-first was the concept we kept in mind and not something that was integrated later on after releasing cmsWorks to our very first clients.
This is one of the primary strengths of cmsWorks, designed from scratch to deliver future needs: Everything in cmsWorks is - literally - a service and thus it is reachable via an API.
That is why cmsWorks has a decisive advantage over other systems that were later altered to be "API fist". The cmsWorks core therefore is best in terms of stability, performance and cost efficiency, because cmsWorks was developed from the very base as an "API-first" system.
The Power of API-First Architecture
Our CMS is built on an API-first architecture, prioritizing the use of Application Programming Interfaces (APIs) for content delivery.
This approach offers unparalleled flexibility, allowing you to serve content to websites, mobile apps, IoT devices, and any other digital touchpoint imaginable.
By decoupling the content management backend from the presentation layer, we empower your team to create rich, engaging experiences across multiple channels without constraints.
Decoupled for Ultimate Flexibility
cmsWorks is a complete decoupled CMS, too, it also separates the content repository from the frontend presentation layer.
This separation brings numerous advantages:
- Freedom of Choice: Developers can use any programming language or framework on the frontend, providing the freedom to create custom experiences tailored to each platform.
- Future-Proofing: As technology evolves, you can easily update or replace your frontend without affecting your content or backend systems.
- Improved Security: With the backend isolated, your content repository is more secure and less vulnerable to attacks.
- Scalability: Handle increased traffic and content volume with ease by scaling your frontend and backend independently.
The proof of that is quite easy to see: in cmsWorks everything is split into own work balances, including content delivery or even the editor's desktop: they all are based on the data-providing CMSCore (micro-)service. Whether it's the generators that deliver pages or the so-called ContentScript server that enables even the most complex workflows with third-party sites or AI integration, or the security mechanisms, all have to ask this very base service API of the "CMSCore" service which may be used to expand the possibilites of cmsWorks as well.
As example, even the cmsWorks WebUI (the editorial desktop which enables the editorial team to make changes) only uses the basic API of the CMSCore service. And all these (micro-)services are independent of each other service, may be expanded at any time, and thus optimally can serve all different kinds of need.
Actually, it even goes a step further: Do you want to give your website a new look and feel? For example adding new generators or exports, RSS or other services, or to publish something in a different way like PDF / some other proprietary format? Simply start a new service within cmsWorks and bring your ideas to life. You don't even have to restart the server or take it offline - neither in programming nor in the live system.
And though cmsWorks initially appears to be launched in a single virtual machine, the tasks and services in cmsWorks are strictly divided into so-called services (microservices in one virtual machine). Each of these services fulfills its own specific purpose. Examples of these are
• Providing a database or establishing a connection to a database.
• Providing an editorial desktop with all editing options, drag'n'drop, inline editing etc.
• Rendering a preview or a "live" page
• Enabling different types of big data search capabillities (for editors and/or for live pages)
• Executing a content script in the workflow engine ContentScript server.
• ...
All of this is made possible by dedicated "lose-couple" services available in cmsWorks. cmsWorks itself therefore always follows the principle of of lose-couple services, not to mention micro-services, internally.
