I intend to use this blog post to track technical concerns to consider before implementing a .NET solution that leverages a headless content management system. Some of these considerations apply to content delivery solutions on any platform and some may apply to service-oriented solutions beyond content management. Linked posts tend to focus on .NET and I work for Contentstack, so concrete examples tend to use that product. If you have additional considerations for headless content management with .NET, please comment on this blog post.
Update 15.Dec.2025: After years of frustration with WordPress, I am finally abandoning this blog. The content will likely stay here for some time, but new content will appear here:
- Certain products attract different developer communities. A .NET CMS may attract .NET developers. While vendor selection is important, the technology behind the CMS product itself need not be ASP.NET, as customers should invoke service APIs or SDKs that wrap service APIs rather than involving platform-native APIs directly. Beware that if the CMS is not ASP.NET, existing examples of customizations and code made available from the vendor will likely use a different server-side platform such as NodeJS. You may be able to use ASP.NET Core to host their UIs and services on which they depend, CMS custom user interface components generally interact with the CMS via JavaScript. You may choose to use Blazor (C# run as WebAssembly on browsers) to invoke the CMS vendor’s JavaScript or to invoke the service endpoints directly, or possibly to use the vendor’s SDK.
- Determine whether and when to use the vendor’s SDK, to access vendor services directly, or whether to access data exported from the CMS rather than accessing the CMS directly.
- Determine which data the solution will access at each point in the application lifecycle (build, serve, render).
- Implement search indexing and usage strategies. My suggestion is to index everything and access search rather than CMS whenever possible.
- Consider whether and how to employ an event system, for example to translate CMS webhooks to events published to other applications that can in turn invoke CMS APIs. ld, serve, render).
- Consider whether and how you will use ASP.NET MVC, Razor Pages, Blazor, static files, and any other technologies to serve HTML and other content types. Services typically use MVC, but Razor Pages can have advantages over the underlying MVC framework.
- Determine if and how to implement Jamstack.
- As with any ASP.NET application, the URL structure and routing are critical. Determine how you will implement routing to support the URL rules for the solution. Determine if and how what URLs will map to entries. Determine how you will generate links including navigation.
- Whether and how to use GraphQL, which constructs queries using proprietary JSON formats rather than proprietary APIs. I prefer to query a search index.
- Implement one or more typed clients to access the CMS.
- Go serverless.
- Consider your toolset.
- Do not forget about robots.txt and sitemap.xml.
- When working with large numbers of entries, beware of paging.
- Focus on data modeling.
- Determine whether to implement entry models or access entry JSON directly. For entry models, determine how field types in the CMS map to .NET types and implement any required infrastructure. Consider exposing the raw JSON as part of the entry model.
- Consider a controller, UI customizations, and other techniques to implement conveniences for developers, such as to rebuild search indexes.
- Determine architectures for integrations such as search, commerce, digital experience management, and otherwise.
- Determine an exception management strategy.
- Consider a repository abstraction pattern and in any caching situation beware of publication.
deliverystack.net 