.NET Repository Pattern for Headless (CMS)

In a previous blog post (https://deliverystack.net/2020/07/23/expose-entry-json-from-entry-model/) I mentioned that I’m using a repository class to abstract access to the CMS, in my case Contentstack (though I have developed partial prototypes for Contentful, Kentico, and elastic). What I mean by a repository is just an abstraction layer on top of the CMS or other system.

A repository implementation can provide the following:

  • A repository abstracts CMS implementation from other projects, including connection configuration. Consumers simply pass identifiers or queries and receive Entry Models of a predefined or requested type.
  • The repository can cache JSON retrieved from upstream systems including CMS. Importantly, the repository can also manage cache eviction and clearing after publication (consider JSON, Entry Models, ASP.NET output, and any other caches), typically using CMS webhooks and/or synchronization APIs.
  • The repository can abstract multiple sources (in Contentstack, multiple Stacks) from multiple providers (vendors and internal systems) of various types (CMS repositories, search indexes, product information management systems, inventory management systems, and otherwise). If the query or Entry identifier includes a provider identifier, designates a Content Type associated with a provider, or otherwise indicates the source system to access, retrieve the Entry from the appropriate provider, otherwise retrieve the Entry from the default provider.
  • Identifiers can be Content Types with or without UIDs, URLs, product identifiers, or anything else, and can include language, version, or other attributes to match (or use separate repositories for separate languages).
  • Implementations can experiment and evaluate performance with different techniques such as preloading all, partial, or no data with content delivery APIs, sync APIs, GraphQL, or directly from a search index.
  • A repository can instantiate Entry Models with data from multiple repositories, for instance pulling marketing content from CMS, product content from a product information system, and inventory data from an inventory management system.
  • If the repository is threadsafe, you can register the repository with dependency injection as a singleton to avoid multiple instantiations (important if caches are in its memory but not static). But then again, your cache should be separate from your repository.
  • A repository easily supports multiple local caching infrastructure options.

Published by John West

I like Twizzlers and um

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: