Default Client Options

[maisarissi]

I used Kiota to generate a customized Go client library targeting the Graph API and have added the Graph Go core library to my project.

When creating a new GraphRequestAdapter the clientOptions is required, forcing users to creating their own clientOptions what might be a strange scenario since the clientOption is used to inject telemetry data around SDK versioning.

Expected:

We should have a default client option where we set up the core library values as default, so when creating a new adapter, the core version will be sent to out telemetry.

authProvider, _ := auth.NewAzureIdentityAuthenticationProviderWithScopes(credential, scopes)

adapterV1, _ := msgraphcore.NewGraphRequestAdapterBase(authProvider)

client := gosdk.NewGraphBaseServiceClient(adapterV1, store.BackingStoreFactoryInstance)

[baywet]

Thanks for starting the conversation on this one. Ideally self-serve consumers would get the same initialization experience as pre-packaged ones, while keeping a similar experience for the Tasks and other benefits from Graph core.

This takes a couple of pre-requisites:

• The dependencies kiota tells them to add should be graph core and not kiota libraries
• They'll need the handcrafted request adapter so telemetry and additional middleware handlers are configured for them
• They'll need the handcrafted graph client so they can initialize valid hosts and scopes (auth), map Me if they desire to do so, and add a getter for the request adapter.

While I've created an issue for the first part, I believe the last 2 items should be part of public documentation (like a tutorial to get their own client in any language, as well as a topic that explain the value of doing so).
Lastly we'll need to decide: do we want to enable backing store for self-served clients? What telemetry values do we want to set for self-served clients?

[baywet]

CC Sébastien Levert (@sebastienlevert) since this is something we'll need to drive across languages

[andrueastman]

Linking microsoftgraph/msgraph-sdk-dotnet-core#712 as well to bring to the surface parallel issue on C#.

[sebastienlevert]

So my thoughts on this one.

Self-serve should act as the "smaller" version of any of our SDK. That means that we should have the EXACT same experience, just without all the API surface.

Any "core" libraries should be part of kiota info and probably be documented as part of the OpenAPI description (any API could document where and how to use these core libraries). The kiota info should offer both scenarios (full Kiota, or with the core sidecar). I'm wondering if we should have some sort of "light" version of our SDK just without the paths, and Kiota would generate the rest (I don't know if the word "sidecar" is the right one, but it's the one that came to mind).

That way the experience is the following:

• Generate a self-serve SDK with just a few endpoints
• Install the required libraries (graph-core + light SDK)
• Documentation helps the user with creating their client

This should also work in the plain Kiota world if developers want to handle everything themselves.

[baywet]

light SDK: do you mean just the two classes we've handcrafted in the service libs? Or do you mean that + all the models?

[sebastienlevert]

Just the classes we handcrafted in the SDKs. And identify how we could "plug-in" the rest of the generated code to this "light" version of the SDK? This would be the best case scenario IMO. But this might be non-feasible and very complex for the scenario.

[baywet]

At least for one of them we can't as it derives from the generated client
The other one is just a place holder to get the information version.
Everything that could be moved from the service lib to core has been. And I'm not sure publishing a new library for a single class will improve the developer experience.

[sebastienlevert]

So we leave this to the developer to build both the request adapters and the clients? Is this what I understand from this?

[baywet]

this is where having examples or even snippets (dotnet templates, yoman generators, etc...) would help close the loop. But in essence yes.

[sebastienlevert]

This is going to be an area where we really need to excel in documenting this. We can't leave that to the developer without any hand holding.