Tool tips: Optimizely Graph Client Tool and how to leverage CMS data models to build query

Read my first blog about Optimizely Graph Client introduction to know its advantages.

Beside Optimizely Graph Client, now we're supporting a tool for generating the schema models into C# model classes. This tool supports for precisely generating models which had indexed to the Optimizely Graph, particularly after Content Delivery has transformed CMS models. You can install then use this simple tool with just a few commands and it's very helpful for query builder and/or deserializing search response.

Notably, with headless architecture, certain properties within the Graph schema and CMS models may differ in name or type, as outlined in our Content Delivery documentation; additionally, our indexing process introduces new properties into the Optimizely Graph's schema models. I suppose that you want to build queries with only existing CMS models (or perhaps your custom models) without relying on the generation tool. We've got you covered with a nifty tip for you.

Using extension methods

One of the most elegant solutions at your disposal is leveraging extension methods. By creating methods with name and return type same as needed properties in the query builder, you could use the methods as the fields for your object model. With just a few lines of code, you can seamlessly integrate extension methods into your CMS models, enhancing their functionality and flexibility.

Consider an example from the Alloy site, where we add Url, ContentType to both PageData, and ContentReference type. We then utilize these methods for querying:

    public static class CmsModelsExtension
    {
        public static string Url(this SitePageData pageData)
        {
            return string.Empty;
        }
        public static string Url(this ContentReference content)
        {
            return string.Empty;
        }
        public static IEnumerable<string> ContentType(this SitePageData pageData)
        {
            return Array.Empty<string>();
        }
    }

And then you can use those methods for field selecting, filtering, and faceting.

var query = _client
                .OperationName("Alloy_Sample_Query")
                .ForType<SitePageData>()
                    .Skip(0)
                    .Limit(10)
                    .Fields(x=> x.Url(), x=> x.ParentLink.Url(), x=> x.ContentLink.Url())
                    .Filter(x=> x.Url().MatchPrefix("https"))
                    .Search(q)
                    .FilterForVisitor()
                    .Facet(x=>x.ContentType().FacetFilters(t));

This way is also useful when you need to select any property in IEnumerable<Your_Data_Type>. Just create an extension method with the same name as your property and return the appropriate type.

Example to select DisplayName from proprerty ExistingLanguages (IEnumerable<CultureInfo>) in SitePageData:

public static class CmsModelsExtension
{
      ...
      public static string DisplayName(this IEnumerable<CultureInfo> cultures)
      {
          return string.Empty;
      }
}
query.Field(x=> x.ExistingLanguages.DisplayName());
query.Filter(x=> x.ExistingLanguages.DisplayName().Eq("English"));

Updating Properties for ContentApiModel (Not recommend)

Another approach involves tweaking the schema models to closely resemble CMS models by adding or removing properties on the ContentApiModel. While technically feasible, we advise caution with this method. It could potentially introduce redundant properties and complicate debugging processes.

In conclusion, whether you opt for the convenience of the generation tool or the flexibility of extension methods, rest assured that we're committed to providing you with the tools and techniques needed to navigate the intricate landscape of CMS models.