Open and close architecture : Explained
Written by : Rashmi Mittal
Customers evaluating or adopting a new Digital Content Management System today are either moving away from an existing one because it fails to meet their evolving needs or are looking to integrate their current print workflows with digital ones. In either scenario, they have a plethora of existing tools and solutions on the periphery that the CMS needs to work with, like a Project Planner or a video streaming provider for example. Add to this - the ever-evolving technical landscape and how digital content is published and consumed and it becomes very important for a CMS to offer the flexibility to integrate third-party solutions or allow for the content to be consumed and published to new platforms.
Quintype has been a visionary of sorts, in the modern CMS space and was built as a headless CMS from the ground up. This allowed businesses to consume the content being created using APIs and distribute it in any form and factor as the consuming platforms evolved. While we offer basic and advanced frameworks that optimally consume APIs to render front-ends and mobile applications, publishers are free to use the APIs for any target platform. We offer various content feeds in supported formats but the feeds can also be tweaked or generated using the APIs.
At Quintype, as we spoke to multiple publishers we soon realized that building native support for all the needs of existing and new publishers would overwhelm the engineering teams and not allow us to build meaningful features that would benefit all our customers and help them grow.
We made webhooks a key aspect of our architecture to allow customers to directly integrate into various states of content creation and publishing. Webhooks can be attached to listen to various state change events in a story workflow. The data flowing in through the webhook can be integrated with another system that consumes the content like a Print CMS. Or the events can be consumed to update a Project Planner like Asana for tasks tied to the content. Publish events for a Collection of Content can be consumed to trigger any other workflow attached to section changes or magazine issue publish events. We continue to add the support for webhooks as we identify more events of interest and thus hope to empower our customers to integrate more external workflows.
When we integrated a Video Provider of choice for searching and embedding videos in the CMS, we had the foresight to create an abstraction layer to allow for integrating multiple providers as plugins that sit behind the abstraction layer. This allows our tech partners or even our publishers to hook to a different provider. The plugins sit in a sandbox of sorts that ensures the security of our core CMS is not impacted. Plugins also need to adhere to some standards and meet our testing requirements before they are integrated.
Spell Checking on the Bold editor is supported using a similar model where the local- specific spell-checking library is plugged-in using an abstraction layer that allows us to integrate other spell checkers that publishers may want to use.
On similar lines, Quintype’s subscription solution, AccessType has adopted an adapter pattern for Payment Gateway integrations. Integrations can be built adhering to the plugin model and are tested rigorously before being approved. AccessType has always used an incoming webhook mechanism to listen to various payment workflow events, this is further leveraged with the adapter model.
As we explore other ways of allowing our publishers and partners to enhance the ecosystem, we are very clearly NOT an open-source CMS. We value the security of the SaaS environment we offer, finding ways to OPEN up the ecosystem for easy enhancements and yet maintaining a CLOSE environment that dictates the security and overall quality of our offering.