In our previous blog post, we discussed the terminology related to headless, some misconceptions about what a Headless CMS is and the problems that headless solutions target. The bottom line is that every CMS with decoupled architecture and robust APIs is headless.
Due to the fact that Sitefinity provides robust APIs and OData RESTful endpoints out-of-the-box (feel free to check out some queries), and you can easily deliver content to any device, the conclusion is obvious - Sitefinity is a Headless CMS.
To illustrate it better, I’ll provide two examples showing how Sitefinity acts as a standard CMS and as a headless one.
As seen in the below image, the traditional Sitefinity CMS has the Editors, Designers or Authors, which add Content through the CMS’s Admin panel. This content is saved in the Database and is used in the pages, again throughout it. When these pages are approved for publishing by an admin user, they are visible for the end users as frontend pages.
When Sitefinity is used as a Headless CMS, we have the following workflow. The Editors, Designers and Authors create content through the Admin panel which is saved in the Database. From an external application, for example an Angular app, we consume OData with API calls. These calls return JSON objects, which can be used in the framework. The end users do not directly access the Sitefinity CMS, but the application which consumes these endpoints.
Using Sitefinity as a Headless CMS could benefit a company in so many ways, but the most important one is the reduction of cost and the time to market. What does that mean? Imagine having an in-house development team, with developers that would have to get familiar with the way the CMS works, how the widgets are used and extended, the presentation layer logic, topology, designs and conventions. Then imagine having endpoints already defined, which the same developers just have to consume and can use the skills they already have.
While taking into consideration the cost, using these endpoints would also benefit the team if there is already an existing codebase, which would only have to be extended, and not rewritten from scratch. As we all know, the longer time it takes to develop a product, the greater the cost is.
One of the reasons companies decide to purchase Sitefinity is to reduce their time to market. Time to market can be further reduced when using Sitefinity as a Headless CMS while the presentation layer is decoupled from Sitefinity. There are many scenarios that can be handled this way. For example – a Single Page Application can be developed to consume Sitefinity’s RESTful endpoints with frontend frameworks like Angular, ReactJS etc.
Decoupling the presentation layer from Sitefinity will potentially deter technical debt to an extent, while the content delivery application will not be affected when Sitefinity is upgraded.
If you missed our position about the CaaS please read it here. In short this is a Headless CMS in the cloud. As we concluded above, Sitefinity is a Headless CMS and in addition has smooth deployment in the cloud, and there aren’t any limitations to use it for Content as a Service. Not only does Sitefinity support deployment on the two most popular public clouds, Azure and Amazon, we have a large number of websites deployed on each every month. Please follow the steps from our tutorials for more details. A big percentage of the Sitefinity public sites are in the cloud which can easily be leveraged to power Content as a Service with very little work.
One of the biggest challenges with the whole headless paradigm is that you have multiple frontends and you cannot track the customer experience automatically. This challenge is eliminated when you use Sitefinity as your CMS and Sitefinity Digital Experience Cloud as the technology to track and improve the customers’ journey. Fortunately, DEC already works with 3rd party applications and no matter what frontend framework you are using, you can track the customers’ interactions. To demonstrate how easy the integration is between Sitefinity DEC and a mobile app, we created an application with NativeScript that is personalized with its help.
We iterated through the main challenges around headless and how Sitefinity addresses them. Now, it is time to review how the current features of the system come in handy in the context of a Headless CMS.
The most important capability for each Headless CMS is the bundle of exposed APIs. All content types in Sitefinity are exposed via OData services and can be queried, filtered by taxonomies, sorted, served for pagination, etc. One very important clarification here is that all of those services are automatically generated by Sitefinity and you don’t need to write a single line of code. Keep in mind that even for the dynamic (custom) content types endpoints are generated too.
When we are talking about content, many times there is a need to define certain workflow strategies, which can be accomplished effortlessly with Sitefinity’s workflow system. Not all users should be able to publish content before someone approves it. The workflow system in Sitefinity can be granularly configured – a separate workflow may be defined for a site, for a set of content types and/or for the pages, or all of the above may be included in a single workflow. On top of it, you can receive an email notification when content is waiting for approval.
Other modules that come with Sitefinity, like SiteSync, Multilingual and Multisite are nice additions to the APIs. For example SiteSync, Sitefinity’s data synchronization functionality, will be beneficial when you have at least two environments, i.e. staging and production, so that content may be created, edited and manipulated in many ways on the staging environment, then pushed to the live environment where it will only be consumed.
Multilingual content delivery is a must nowadays in the content-rich web landscape – another goal made simple by Sitefinity’s multilingual functionality. Content may be translated and then served in a native content delivery application by consuming Sitefinity’s OData endpoint, for example:
The Multisite Management Module in Sitefinity CMS is one of the best features that the product has to offer. With the help of the module, multiple sites can be created while keeping content separated per site, or shared between multiple sites. Multisite module allows different sites to be configured with different internationalizations, for example site A may be configured to have English and German, while site B can have English and French or another desired combination of languages.
Example query for querying content items from another site in a multisite configuration:
Example query for querying content items from another site in a multisite configuration with multilingual content:
Email campaigns can also be utilized while using Sitefinity as a Headless CMS. Although functionality such as a newsletter subscription is not provided out of the box as a RESTful route, one can easily be implemented with an ApiController that follows the implementation of the out-of-the-box Subscribe form widget and vice versa for the Unsubscribe logic. From this point on Sitefinity’s Admin panel will provide the necessary tools for the creation of mailing lists, email templates and campaign reports. The whole architecture of Sitefinity is so extensible that you can implement features in no time.
Finally, having a UI that makes managing content straightforward is one of the greatest advantages of the Sitefinity CMS. For Editors and Authors it is an important aspect because the user-friendly design eases the work process. The Sitefinity team is working very hard in this direction and with version 10.2 we reimagined the content creation process in the admin panel.
View all posts from The Progress Team on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Subscribe to get all the news, info and tutorials you need to build better business apps and sites
Copyright © 2019 Progress Software Corporation and/or its subsidiaries or affiliates.All Rights Reserved.
Progress, Telerik, Ipswitch, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.