The GraphQL schema used by Content Hub ONE is the same as that used by Content Hub. But there are a few differences between the two systems and the resultant GraphQL schema used by the Experience Edge tenants for these systems. In this post I’m going to explore the key differences you’ll find when working with an Experience Edge tenant for each of these systems.
Experience Edge hosts tenants for a number of different Sitecore systems including XM, XM Cloud, Content Hub and Content Hub ONE. However, the data models of the Content Hub based systems is different to that of the XM based systems, so each requires a different GraphQL schema to access the content which has been published to Experience Edge. In this post I’m going to explore the GraphQL schema which is generated for a Content Hub tenant.
Sitecore Experience Edge is a multi-tenant system hosting tenants for a number of different Sitecore source systems. The data models of each source system are quite different which requires a different schema in the GraphQL API for each kind of source system. In this post I’ll be exploring the GraphQL schema used for XM tenants on Experience Edge. This schema is used by XM, XM cloud and managed cloud XM instances.
Experience Edge is a SaaS offering from Sitecore which allows users to publish content and retrieve it via a globally available GraphQL API. The service takes on the burden of scalability so you don’t have to. It provides a buffer between your content delivery applications (statically generated sites (SSG), server side rendered sites (SSR), kiosk applications, mobile applications, etc) and your headless CMS (Content Hub or Sitecore XM/XP) which allows the CMS to go offline for upgrades or maintenance without losing the ability to serve dynamic content.
Kafka is a great piece of technology for integrating disparate applications in a decoupled manner. It does however have some nuances which are important to understand. I’ve been tripped up a few times while doing local development, so I thought I’d write it all down in the hope of saving someone else some frustration.
This is the final post in my “Unit Testing Sitecore Components” series. In this series I’ve taken a seemingly simplistic Sitecore component and refactored it by applying several principals to make the code more reusable and testable. In this final post of the series I’ll recap the principals and provide a few resources to help explain them further.
In the previous posts of this series, I’ve refactored an existing Sitecore component to make it’s logic more reusable and prepare the component and the logic it includes for unit testing. In this post I’ll be writing the unit tests for the refactored EntryTaxonomy class, showing how to mock items and field values.
WeBlog 4.1 has been released. The main feature of WeBlog 4.1 is support for Sitecore 10.0. You’ll find the Sitecore packages for various Sitecore versions on the release page at https://github.com/WeTeam/WeBlog/releases/tag/release%2F4.1.
In the posts of this series so far, I’ve refactored a sample view rendering to make the rendering itself unit testable. In doing do I’ve extracted the business logic to a separate class which still needs some work before it can be properly tested. In this post, I’ll be covering 2 more principals to help with making Sitecore components more testable and reusable.
In the previous post of this series I detailed 2 principals which can help with making Sitecore components more testable and reusable. These were “keeping the business logic out of the view” and “keeping the Item class out of the model”. In this post I’ll detail several more principals to continue improving the code.
At the end of April (2020), I had the great pleasure of presenting at the virtual SUGCON conference online. My presentation was a live walkthrough showing how to unit test a Sitecore component. In the presentation I utilised many principals to refactor and improve a view rendering.
WeBlog 4.0 and 4.0.1 have been released. Version 4.0.1 is a bugfix release, so it’s recommended to use that over the 4.0 release. You’ll find the Sitecore packages for various Sitecore versions on the release page at https://github.com/WeTeam/WeBlog/releases/tag/release%2F4.0.1.
The Sitecore Item class is very flexible. But this flexability is a double edged sword. All too often, it’s tempting to simply pass items round your project API without creating a separate, explicit model. This can have performance implications when you need to scale and support 1000s of items.
Sitecore 9.0 introduces the evolution of xDB, xConnect. xConnect is a complete (almost) rebuild of the customer behavior collection and reporting capabilities of Sitecore (plus more). These capabilities are now delivered through a new set of separate applications. In this post, I’ll be introducing you to the Reference Data Service, which is a completely new capability that was introduced with xConnect.
Early this week I released Revolver 3.2. This release includes many small features I wanted to include in release 3.1, but I didn’t want to delay that release just to fit them in. But there is one major new feature, Sitecore 9.0 support. For full details, find the Revolver 3.2 Release on github.
Earlier this week, I released Revolver 3.1. This was a smaller release, but still has some interesting features. For full details, check out the Revolver 3.1 Release on GitHub.
Back in January I wrote an article about how to Roll your own Sitecore Item, which showed how to create an in-memory Sitecore item for use in testing. The technique was quite limited and still required some small config entry to allow everything to work (to create a Database instance). Well, Sitecore 8.2 has finally made a reality what so many of us have prayed for, for so long. We can finally mock Items and Databases with Sitecore 8.2. Though, it’s probably not quite as simple as you might hope.