SDL announced with upcoming Tridion Sites 9 that they also release a new version of their Unified Delivery Platform (UDP) and Content API with GraphQL. The most promising feature of it will be a completely new public-facing Content API. This API is the new endpoint for content delivery for Sites and Docs and help customers enabling more dynamic and cleaner solutions for their channels.

Unified Delivery Platform update

SDL marketing is trying to rename their technology all the time. We have seen it with Tridion to Web to Tridion. And now what once was Content Delivery (CD) was renamed to UDP and now the introduced a new term: Dynamic Experience Delivery (DED). I will keep UDP for now in this article. :-)

Before we dive into Content API, a short highlight of the other key features of UDP 11:

• Multiple namespace support. Now one for Sites and one for Docs. This can be extended to more areas in the future.
• Content mashups possible. Mix content from Sites and from Docs in a single web application.
• Full-text search supported with Elastic Search technology. Index and Query support is expected with Sites 9.1
• Docker support. Making cloud orchestration for the microservices easier (scaling and failover scenarios).
• Content API

Content API

The new content API uses GraphQL which has roots in Facebook technology stack. GraphQL has several benefits compared to other query languages:

• Single endpoint without versioning required
• Efficient querying: specify the information you need and get data in one single-trip request
• Stability: changing data doesn't require changing clients
• Documentation: simple understandable Graph schema with self-documented feature
• Support: large community resulting in a large number of GraphQL client tools

Since GraphQL can be consumed by a lot of other platforms it is likely that it will replace the OData web services at some point in time.

Example GraphQL query for the Content API

When installing the Content API the default endpoint will be something like https://YOURSERVER/udp/content. Note that there is also another endpoint for developers without caching. One requirement is that the content is published as DXA (DD4T) rendered JSON. So if you have this in your broker database, no republish actions are required at all and you're good to go.

In the GraphQL example below, we request 3 properties of a published page by URL.

{
  myPageByUrl: page(namespaceId: 1, publicationId: 5, url: "/index.html") {
	url, 
	itemId,
	title
  }
}

myPageByUrl is the container where the query result can be found in the response. The namespaceId corresponds with Tridion Sites and the publicationId and url is the rest of the actual search query. In the inner query we declare 3 properties what we want to receive in the response: url, itemId and title.

A possible response from the Content API could be:

{
	"data": {
		"myPageByUrl": {
			"url": "/index.html",
			"itemId": 123,
			"title" : "000 Home"
		}
	}
}

More complex GraphQL queries

The given example is fairly straightforward and simple. More complex and useful queries can be made as well. To give you an impression of the almost endless possibilities:

• Get the binary component by ID and by URL 
• Get contained ComponentPresentation's by page ID and by URL
• Get items as paginated results
• Get first X publications
• Get category and its children keywords
• Query for component presentations based on taxonomy
• Get keywords and structure groups related to the page, find parents and expand children
• Mashup queries (retrieving content from Sites and Docs namespaces in single request)
• Get items based on query with custom metadata

Probably during Tridion Developer Summit there will be presentations about the Content API with rich GraphQL demos. TDS is hosted in Amsterdam on 6th and 7th september. It is still possible to register and maybe see you there!