Jeremy Davis
Sitecore, C# and web development
There was a lot going on at SUGCON EU in Antwerp last week. A lot of great community content, the usual fun bar/corridor conversations with other attendees, and plenty of (way too much?) food. But I want to single out some of the announcements Sitecore made in their keynotes and sessions, because there's some really important stuff there for our future work on the platform.
An interesting point here is that most of these things were mentioned at Symposium & the MVP Summit back in October, but we've very rapidly gone from future ideas being suggested in those talks, to running demo code for this event. The speed of movement bodes well for their commitment to future improvement, and will be putting a lot of interesting tech in our hands pretty soon.
But out of all the content, there are the three things which I think will have the biggest and most immediate impact on us as developers and users in the future:
(Excuse the slightly dodgy images of slides - I've done my best to sort them out, but it's never that easy to get good pictures from a projector screen when you're sat in the audience of a session)
url copied!
A while back Sitecore forked the XM codebase to have separate copies of the back-end for platform DXP and for XM Cloud - in order to allow the products to evolve in different directions at their own rates. They're now repeating that process with JSS to create a new "optimised for XM Cloud" version of that framework, named "Content SDK" to differentiated it from traditional JSS. Liz Nelson and Christian Hahn spoke about this, and described their decision-making and achievements since Liz had discussed some of this approach in Dublin last year.
They've started by stripping out a good chunk of code which XM Cloud does not need. The key change here is that all of the logic for the older "Chromes" model that Experience Editor required for its WYSIWYG editing is gone now, so the system only runs the more modern "Metadata" model that was introduced recently. And they've also renamed and refactored the packages which the main JSS code depends on.
They argue that this makes life easier for developers, as there's less complexity to add on top of a basic Next.js site, and that you get much less stuff on disk while you code, or compiled into your front-end bundles. They talked about the on-disk size of the starter kit site folder dropping from 8MB down to 600KB and the bundle size roughly halving in their new approach.
They've also changed the SDK's approach to adding middleware to your site. Previously this followed a plug-in model where it could be difficult to control ordering of these add-ins. They've moved to a new "piped" approach where there is a single line of code in your solution which specifies which middleware to run and what order it should go in.
There are further changes around rationalising config for your site down to a single file, and getting rid of lots of noise in the lib & temp folders of a site. Plus the approach to Static Props has changed a bit. But they say that (outside of metadata vs chromes for editing) the model for UI controls has not changed.
And overall they think they've achieved a 200ms improvement in the First Contentful Paint (FCP) metric on average and you can now add roughly 10x as many components to an editable page and still get decent editorial performance.
These new libraries and their revised documentation are available now and while these packages are currently "in Beta" they suggest that the go-live release will come soon enough that new projects should consider starting from this revised library to save rework in the near future.
url copied!
A core challenge with moving from Platform DXP to XM Cloud has been the loss of all the features around "install 3rd party extension packages" and "customise the editing experience" due to the move to SaaS delivery. The solution to this problem is an extensions framework for Sitecore's modern SaaS tools which is being trialled now. This allows you to write custom web applications using a new SDK, which can plug in to specific "touch points" in the portal.
The current scope for these integration touch points is to allow creating:
For future scope they're talking about extending this model out to Content Hub's UI and to the Personalize / CDP parts of the Sitecore portal as well.
They're looking to offer three models for how your apps are made available:
Public ones can be used by anyone. Single Tenant custom applications are just for you, and nobody else can use them, while "Multi-tenant" apps aren't available for general install but can be deployed to multiple people. (Likely agencies building tools to reuse for across their customers)
We saw two presentations on this topic at SUGCON this year. Spiros Misichronis and Liz Nelson talked about the general approach and Krassi Eneva and Justin Vogt talked more detail about the SDK that's being built for this. And they showed some example UI. Here's an extension adding a panel to Page Builder after being invoked from the "extensions" menu dropdown:
The "jigsaw piece" icon on the top right is the dropdown allowing you to start any relevant extensions that you need. (From the set you've previously installed and configured) And the panel in the middle of the UI has been injected by the app which was picked - and it is rendering a variety of data extracted from the context of this Page Build editing session as a basic example here.
They also talked a bit about what you need to do on top of writing custom apps - which is broadly "host the code" and "provide the support to users" for them. And they discussed the approval process which will be necessary for any apps you build to be made public. Things like security audit, and checks on how they fit in with the portal's UI styles.
This stuff is working now, and they have some partners and other developers working on some initial applications using the current extension framework. They gave examples of tools to copy content between XM Cloud environments and integrating a 3rd party content translation service directly into the UI.
So we're not too far away from having our extensibility back.
url copied!
The third big change that was discussed is being referred to as "XM Cloud Content" now, but had previously been discussed as "Content Service" in some presentations. This is the most dramatic of all the changes, as it is the new data back-end which will eventually store and deliver all the content you put into XM Cloud. It is basically the replacement that will allow the removal of the "XM" (and docker-based services) from XM Cloud.
Interestingly, Alistair Deneys described this as "A CMS" in its own right - which makes sense. To be a data model for XM Cloud does imply a feature set which would allow it to do the same job for other front-ends. So potentially it's scope will be wider than just enabling a much more "pure SaaS" approach to running XM Cloud in future?
At the moment this exists as a set of API services which can perform the core tasks of content modelling and delivery:
None of those are novel concepts compared to the services the old XM/XP data layer provided, but this implementation works very differently in order to address some of the common problems and feature gaps we've worked around over the years.
Firstly, publishing is no longer a "copy data between physical databases" operation - it's just flipping a flag on the content item - basically setting
isPublished = true
on the data. This makes publishing practically instant for your changes.
Secondly, this doesn't follow the "tree structure" model for content we've been used to in the past. Here the system's model uses Taxonomy to categorise content, rather than relying on the parent-child relations of items. (Though that relation is still possible with the
Reference
field type if you need it) Their overall data model looks like:
Another change you may spot from that diagram is that the new model no longer uses inheritance to combine together bits of schema. In the new world they've moved to a "composition not inheritance" model - so you can combine together "fragments" of schema to enrich your content items. So in future any content item (with any Content Type) can go in your "media library" as long as you've added the correct "media data fragment" to it. The example shown looked like:
This makes for greater flexibility when you don't have to explicitly inherit from a base type.
This model also has versioning. But now a "published" item version is immutable and cannot be changed. Draft items are editable, but once you publish you have to create a new version and publish that (archiving the original) to replace some content. This allows for an easier approach to viewing the state of a database in the past - you know if you set the filter to "show items that were live on 28th January" then these will not have been changed since then. Unlike in the current model where an item might be marked as "version is valid on 28th Jan" but it is still possible for the content to have been changed.
There are two APIs for handling this content. A one which is used to manage the schema/data and one which is used to deliver the content to website front-ends. That delivery API keeps the GraphQL approach that we have currently with Experience Edge for delivery, but extends it with some new ideas. An example here is that your Content Types can be marked as whether they should appear in the top level query objects for GraphQL in order to simplify the GQL schema help and queries. And there's more scope for creating API tokens with restricted access to subsets of your data.
There's a bunch of other change here all aimed at making this new model faster and better for managing the content in XM Cloud and delivering it to head applications. And there's a chunk more roadmap stuff that's being considered here for the public release of this tech later.
Unsurprisingly for the biggest change that was talked about at the conference, this is still in early development. Only the first pass at the APIs exists for this right now - the revised UIs and proper SDKs have still to be built. But I expect to see a lot more on this come Symposium time.
url copied!
There's an old saying that the only constant in IT is change - and that really seems like reality for the Sitecore ecosystem these days. After some years of "the core APIs from Sitecore v6 are pretty much the same in v10" we're now in an era where more significant stuff is changing quite regularly. But I think this is important change - it's making products better for our projects and our users.
Exciting times. I'm looking forward to getting to play with these now.
↑ Back to top
