TL;DR
Has anyone been able to use seo-friendly, bucketless urls with the GraphQL Layout Service?
Environment
- Sitecore 10.2 XM
- Headless 20
- NextJS Rendering Host
- SXA 10.2
- SPE 6.3
Background
In traditional, MVC-rendered sites, a Sitecore developer has historically been able to eliminate buckets from urls using a combination of a custom link manager and an item resolver that executes within the httpRequestBegin
pipeline.
In a headless implementation, the GraphQL Layout Service is the recommended API for retrieving Layout content for a route.
In Sitecore, I have a folder with 1000 routes, each corresponding to an individual Biography. Each item is named after a person. This folder is bucketed by the first letter of the item name.
Folder Structure Example
- /people
- /a
- /b
- /c
- /cheeto-bandito
I want to setup my GraphQL query like this:
query () {
layout(site: "MainSite", routePath: "/people/cheeto-bandito", language: "en") {
item {
rendered
}
}
}
Expected Result
The Layout Service is able to resolve the item provided in the routePath
parameter based on my Custom Item Resolver.
Actual Result
{
"data": {
"layout": null
}
}
The httpRequestBegin
does not apply here. I haven't found a pipeline that I can use to influence the ItemResolver process in the Sitecore.Services.GraphQL.EdgeSchema.Queries.LayoutQuery
.
My best bet would be to override the IContentService
that's registered in the Sitecore.Services.GraphQL.EdgeContent.config
file included with Headless 20.
<register serviceType="Sitecore.Services.GraphQL.EdgeSchema.Services.IContentService, Sitecore.Services.GraphQL.EdgeSchema" implementationType="Sitecore.Services.GraphQL.EdgeSchema.Services.ContentService, Sitecore.Services.GraphQL.EdgeSchema" />
So far I haven't had much luck with this. This might be due to the fact that Sitecore doesn't seem to have published a Nuget package for Sitecore.Services.GraphQL.EdgeSchema
that's compatible with Sitecore 10.2.
Alternatives Explored
If my site was entirely SSG, I could return a friendly url and an internal path as part of the Sitemap Service response. Unfortunately for us, this site is large and we're using SSG and ISR to keep build times to a minimum. This means that not every route is returned by the Sitemap service.