You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow for alternate SDK versions #52 (as well as V1 vs. V2 connections, or leaner HTTP only based implementations (refit?)) and alternate implementations to other ecosystems (though not a priority for us, would allow controls better re-use for others).
Describe the solution
Was thinking now that we've started isolating the authentication method in #76, that it may make sense to extend that to the Graph SDK itself. If we create a common interface for any calls we need to make, that can be in our base packages and referenced by our controls package, but then we could put the implementation that drives the controls in a separate packages. Then hook them up later.
This would provide a number of ways to implement the connection to the Graph which should let us:
Connect to Beta End-point
Connect to V1 End-point
Support both V1 and V2 Graph SDKs when the later releases hopefully?
Create a leaner HTTP only implementation without an explicit Graph SDK reference, maybe using refit or something else?
Allow others to connect to other ecosystems outside of graph to re-use controls.
Just like authentication, we don't have to make assumptions or dictations on what apps have to use to leverage the controls themselves to improve their apps.
Hello michael-hawker, thank you for opening an issue with us!
I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌
Describe the problem this feature would solve
Allow for alternate SDK versions #52 (as well as V1 vs. V2 connections, or leaner HTTP only based implementations (refit?)) and alternate implementations to other ecosystems (though not a priority for us, would allow controls better re-use for others).
Describe the solution
Was thinking now that we've started isolating the authentication method in #76, that it may make sense to extend that to the Graph SDK itself. If we create a common interface for any calls we need to make, that can be in our base packages and referenced by our controls package, but then we could put the implementation that drives the controls in a separate packages. Then hook them up later.
This would provide a number of ways to implement the connection to the Graph which should let us:
Just like authentication, we don't have to make assumptions or dictations on what apps have to use to leverage the controls themselves to improve their apps.
FYI @shweaver-MSFT
The text was updated successfully, but these errors were encountered: