3

We are trying to implement a dynamic page behavior that will resolve pages for non item existing routes like:

https://mywebsite/stores/store1/ (Stores exists as item but store1 not)

The idea was that: The the dynamic page route of Next.js (...path) will forward the request to layoutservice with item parameter: /stores/store1. And on backend side we would resolve the item to an existing item and enhance data from url to provide page layout service data.

But for now it looks like that Next.js is calling always the GraphQL endpoint /sitecore/api/graph/edge and that is the request url for the "layout" somehow? But to be honest, we currently not understand if the endpoint is used to access the layoutsource data, or if it is triggered in addition and just raising because of non existing item a graphql error.

Can someone explain how this works? And if our approach even make sense?

Improve this question

1 Answer 1

Reset to default
1

With Next.js, the API works differently to the other flavors of JSS, it no longer uses the layout service. As you have seen, it calls the GraphQL endpoint at /sitecore/api/graph/edge - this is effectively the same schema that Sitecore Experience Edge uses.

This schema contains entry points for item, layout, and search. Rather than resolve the data on the backend, it might be better to make the call in getServerSideProps, if the response from GraphQL tells you the item doesn't exist, you can then get the known existing item and enhance the data before returning the props for the page.

References:

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.