Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Context Support #18

Merged
merged 7 commits into from
Oct 1, 2024
Merged

Context Support #18

merged 7 commits into from
Oct 1, 2024

Conversation

sc-ivanlieckens
Copy link
Collaborator

Description / Motivation

This allows creating connections to the Edge using the Edge Platform Context instead of an ApiKey. It introduces new extension methods on the SitecoreLayoutClientBuilder called AddGraphQlWithContextHandler for the LayoutService.Client and enhances the extensions on GraphQlConfiguration called AddGraphQlClient for the GraphQL. Introducing ContextId to the SitecoreGraphQlClientOptions as well as by default using the https://edge-platform.sitecorecloud.io/v1/content/api/graphql/v1 endpoint instead of throwing an exception when passing in a ContextId.

Moving forward Sitecore and XM Cloud in particular will greatly rely on the unified Edge Platform endpoint with ContextId making this an important addition to the SDK.

This resolves #10

Testing

  • The Unit & Intergration tests are passing.
  • I have added the necessary tests to cover my changes.

Terms

@sc-ivanlieckens sc-ivanlieckens added the enhancement New feature or request label Sep 13, 2024
@sc-ivanlieckens sc-ivanlieckens added this to the Symposium Release milestone Sep 13, 2024
@sc-ivanlieckens sc-ivanlieckens self-assigned this Sep 13, 2024
@sc-ivanlieckens sc-ivanlieckens marked this pull request as ready for review September 27, 2024 21:49
@robearlam
Copy link
Member

@sc-ivanlieckens This all looks good, one question I had was whether we want to handle the developer making a mistake and providing all config sections for both ContextId approach and ApiKey approach.

Should we throw an exception in that case, like we do when both are missing, to force the developer to tidy it up and be explicit about the approach they want to use?

@sc-ivanlieckens
Copy link
Collaborator Author

@sc-ivanlieckens This all looks good, one question I had was whether we want to handle the developer making a mistake and providing all config sections for both ContextId approach and ApiKey approach.

Should we throw an exception in that case, like we do when both are missing, to force the developer to tidy it up and be explicit about the approach they want to use?

Actually I don't want to prevent that, it might be a very rare case but you might want to be running 1 site off XM on-prem and 1 site from XMC with the same head. You're simply registering handlers and which handler is the default is your choice and you can configure as you like/need. Does that make sense?

@sc-ivanlieckens sc-ivanlieckens merged commit f85e740 into main Oct 1, 2024
3 checks passed
@sc-ivanlieckens sc-ivanlieckens deleted the feat/context-support branch October 1, 2024 06:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

Add support for ContextID Connections
3 participants