This blog post intends to clarify an apparent misunderstanding about .NET with headless CMS, which is that you can use Azure and .NET with any SaaS headless CMS, whether or not that CMS uses .NET internally. If you can use SaaS for headless CMS, then consider all available SaaS headless CMS offerings regardless of underlying technologies rather than restricting yourself to those implemented in ASP.NET Core and running on Azure.
While reviewing search terms that generated search result links to this blog, I noticed some patterns. One is that people frequently search for terms such as the following:
- ASP.NET headless CMS
- ASP.NET Core headless CMS
- .NET headless CMS
- .NET Core headless CMS
- Azure headless CMS
What is often missing is SaaS, which is necessary to achieve the best return on a headless CMS investment.
One of the goals of SaaS headless CMS is to decouple content management from content delivery, where SaaS headless CMS vendors are responsible for content management environments and content delivery services and customers are responsible for content delivery solutions. This decoupling results from using HTTPS services for content delivery rather than platform native APIs. The headless CMS should appear to developers as a black box that exposes JSON over HTTPS APIs, can generate webhooks, and allows extension of its browser-based management UI.
From this perspective, the hosting platform and technologies used to implement the CMS should be irrelevant to architects and developers implementing content delivery solutions. Customers can use ASP.NET Core or any other technology to implement the content delivery tier consuming JSON from the CMS over HTTPS content delivery services. The same is true for customizations using webhooks and content management APIs.
Regardless of underlying technologies, it is more important to choose the SaaS headless CMS that best matches solution requirements, especially around data modeling. In this context, the availability, API coverage, and other aspects of the .NET SDK from the CMS vendor may be more important than whether the back-end uses ASP.NET Core or runs on Azure, although there are advantages to implementing your own typed client rather than using an SDK.
There are some valid reasons to consider the CMS back-end technology and hosting platform. Customer may intend to contribute source code to the CMS or host their own solution rather than using SaaS from a vendor. Organizations using the Azure cloud may optimize performance by accessing SaaS systems in the same environments as their content delivery solutions. Due to the need to implement and maintain SDKs, SaaS headless CMS vendors generally have some competency in a variety of mainstream technologies, but technologists working for the vendor are likely to be most fluent in the programming languages and toolchains used to implement the CMS.
If you know of other reasons to avoid SaaS for headless CMS or to require Azure or .NET, please comment on this blog post.
Deliverystack.net 