This blog post describes techniques that you can use to syndicate content from one headless content management system to others from the same CMS vendor, typically from production to test, development, and other systems.
Organizations often deploy separate instances of a content management system for development, test, production, and potentially other purposes. Changes to content types and other developer resources flow forward from development through test and to production. Some content initiatives may begin in development or test and follow the same path.
For proper testing, content including text and media assets should flow backwards from the production content management system to test and even development systems. Organizations have several options to achieve this objective:
- CMS user interface (manual)
- CMS content delivery APIs (write code)
- CMS command line interfaces (script or interactive, a higher level of code)
Consider both initial and ongoing synchronization processes. Initial synchronization is important for instantiating new systems or resetting existing systems. Ongoing processes can automate synchronization updates that might otherwise require manual operation or result in use of stale data in non-production systems.
You can use CMS update or publish webhooks to trigger synchronization to other systems.
Content delivery may include specific synchronization APIs that facilitate syndicating data between systems. In this case, a webhook (preferably indicating batch publishing completion) or an event bus can trigger a process that uses the synchronization APIs, which can be more efficient than processing individual update webhooks or calling more general content delivery APIs for synchronization, such as iterating entries by content type.
When synchronizing data, remember to consider search indexes, caches, and other elements of systems that data changes may impact.
You may need to manage configuration or metadata to control which data to synchronize and implement a process for reconciliation. For example, if an entry has changed in the test system but not in production, you may not want synchronization to overwrite its values in the test system, and you may want to generate a report that accesses both systems to list all entries that have this condition.
If you can use an event management system, you may want to implement handlers for update webhooks in the production CMS that pass information through the event system to the other CMS systems. Events should indicate which system generated them (development, test, production, or otherwise).
If you have any additional perspective on synchronizing content management systems, please comment on this blog post.
Deliverystack.net 