SDL Tridion Sites 9.1 – Beyond DXA 2.0 - part 1

We have reached the final topic in our series about the new features surrounding SDL Tridion Sites 9.1. As with my previous blog about the Tridion Integration Framework, this topic will also be split into two because of its volume.

I assume you’re already familiar with DXA so I won’t be explaining the framework in detail, instead I will focus on the differences between versions, on how the framework has evolved through the years, and finally, what the future plans are.

If you’re not familiar with DXA however, a good starting point is the official documentation.

DXA 1.x -> 2.0

Let’s start by taking a look at the DXA 1.x architecture compared to 2.0. Both architectures are illustrated below:

• The green rectangles represent parts of the system where custom implementation is expected
• The blue rectangles are part of the DXA framework
• The gray rectangles are part of the Content Delivery (CD) (the Dynamic Experience Delivery (DXD) prior to SDL Tridion Sites 9)

The biggest change between versions 1.x and 2.0 is the introduction of the Model Service (MS). I’ve already described the MS in more detail in one of my previous blogs, but to summarize:

• The MS CD microservice is implemented as a REST service which should be installed as close to the (Session Enabled) Content Service (CS) as possible, ideally on the same box. (note, changed in DXA 2.1)
• The MS is exposed as an extension property of the CS and is “discoverable” through the regular channels (Discovery Service) (note, changed in DXA 2.1)
• The job of the MS is to build the requested page’s model (including the contained entities) and return it to the DXA web app in a single response. The effects of using the MS is a significantly reduced number of round-trips between the web application and the Broker
• The MS uses CIL to talk to the CS to get data from the Broker
• DXA has a Model Service Client which communicates with the MS microservice
• The MS handles dynamic data expansion and link resolving
• The MS is capable of data conversion between different formats (DD4T and R2), making migration scenarios more easy

Another big change was the introduction of the aforementioned R2 data model, which is much less verbose than the DD4T data model used in version 1.X. The use of R2 additionally speeds up the web app’s response and publishing.

While the CIL layer has played a crucial part in 1.X,as DXA has changed, the general strategy has evolved to slowly phase out CIL completely. By looking at the picture above, you can see that it is still used for Publication/localization resolving, and a few other things; the goal hasn’t yet been accomplished.

“In-process” Model Service

In the previous section I’ve mentioned that the MS uses CIL to communicate with the CS to retrieve data, and while this is true by default, there is a hotfix which changes this! It’s called the “in-process Model Service” and has the name because it uses the in-process APIs to directly communicate with the Data Layer/Broker.

Although the use of in-process APIs results in a much higher performance, it reintroduces the tight coupling with specific versions of the CD and the need for a number of external dependencies which the microservices architecture had previously addressed.

Factors that contribute towards achieving better performance:

• No HTTP/OData (de-)serialization overhead
• Much less ADF overhead
• Leverages Tridion Object Cache (incl. cache invalidation)

DXA and CD version coupling:

• DXA 2.0.x → CD 8.5
• DXA 2.1.x → DXD 11.0
• DXA 2.2 → CD 8.5

DXA 2.0 Hotfix Releases

The last topic I want to cover in this blog is related to DXA hotfixes. Although the heading says 2.0, the information listed below applies to all versions.

Because DXA is open source, the way how hotfixes are made available is different than for other SDL products. DXA (both the source and the compiled artifacts) is available on GitHub and consists of a number of repositories prefixed DXA, all of which contain specific parts of the framework.

Similar to the framework itself, hotfixes are also available as GitHub releases, labeled as “Pre-release”. Not the most appropriate type, but this is a GitHub limitation as it has no dedicated hotfix label. Each hotfix contains release notes about which fixes it includes, and each hotfix is tagged using the format DXA_[version]_Hotfix (e.g. DXA_2.0.3_Hotfix). Using the tag you can easily find the associated sources.

Depending on the hotfix type, the compiled artifacts are either attached to the GitHub release itself, or are available through Maven/NuGet.

As mentioned earlier, this is quite a big topic, so I’ve decided to split it in two blogs and this would be all for the first one :). The second part of this topic will be arriving shortly.

As always, if you have any questions or would like to share your thoughts, don’t hesitate to get in contact.
Disclaimer: All images are copied from SDL with their permission.