diff --git a/design/assets/service-library/child-resources-remarks.png b/design/assets/service-library/child-resources-remarks.png new file mode 100644 index 000000000..5d94510df Binary files /dev/null and b/design/assets/service-library/child-resources-remarks.png differ diff --git a/design/kiota-e2e.md b/design/kiota-e2e.md deleted file mode 100644 index 31e776c5a..000000000 --- a/design/kiota-e2e.md +++ /dev/null @@ -1,229 +0,0 @@ -# End-to-end usage of kiota-generated SDKs in Javascript - -While working with the Kiota + Javascript teams, it became clear that we needed more context and provide a better vision on how we should be using a kiota-generated SDK. This design document aims at providing clarity and a better understanding on how developers will be using our SDKs and the underlying kiota packages. - -## Status - -| Date | Version | Author | Status | -| ------------------- | ------- | ---------------- | ------ | -| February 15th, 2022 | v0.2 | Sébastien Levert | Draft | -| January 17th, 2022 | v0.1 | Sébastien Levert | Draft | - -## Constraints - -Before we jump into the end-to-end walk-through, it's important to set some constraints. - -| Type | Environment | Description | -| --------- | ----------- | ------------------------------------------------------------------------------------------------- | -| Platforms | Node | Current and Previous LTS (14 / 16) | -| Platforms | Web | Edge, Chrome, Firefox and Safari (Latest released version + immediate previous version) | -| Modules | Node | ESM + CJS | -| Modules | Web | ESM | -| Types | All | Typings / Models should be available for both the core and the service libraries for Graph models | - -## Table of Contents - -- [NodeJS e2e using the Service library](#node-service-library) -- [NodeJS e2e using the Core library](#node-core-library) - -## NodeJS e2e using the Service library - -### Concept - -This example is utilizing both the core and the service library. That means that as a developer, we want the full fluent API, allowing me discover APIs via the intellisence. Because the service library leverages the core library, we also want to highlight that we can leverage the core components directly (like the `.api()` method). - -### Install the Microsoft Graph Javascript Service Library - -There will be two versions of the service library for the Graph Javascript SDK. The default one will bring the representation of the v1.0 of Microsoft Graph. The second one will bring the representation of the beta of Microsoft Graph. This will be the only difference between these two libraries, as all the handcrafted code (delivering authentication, middlewares, tasks, etc.) will happen in the core library. - -The Microsoft Graph Javascript Service Library includes the following packages: - -- `@microsoft/msgraph-sdk-javascript` ([npm](https://www.npmjs.com/package/@microsoft/msgraph-sdk-javascript-core)) - The service library for making fluent calls to Microsoft Graph v1.0. -- `@microsoft/msgraph-sdk-javascript-beta` ([npm](https://www.npmjs.com/package/@microsoft/msgraph-sdk-javascript-type)) - The service library for making fluent calls to Microsoft Graph beta. - -You can use [npm](https://www.npmjs.com) to install the Microsoft Graph Javascript Service Library : - -```shell -npm install @microsoft/msgraph-sdk-javascript --save -``` - -### Importing the right functionalities from the Graph Javascript Service Library - -```typescript -// App.ts - -import { Client } from "@microsoft/msgraph-sdk-javascript"; -import { User, Message, BodyType } from "@microsoft/msgraph-sdk-javascript/models"; - -// The authentication providers would get re-exported from @microsoft/msgraph-sdk-javascript-core/authentication -import { AzureIdentityAuthenticationProvider } from "@microsoft/msgraph-sdk-javascript/authentication"; -import { DeviceCodeCredential } from "@azure/identity"; -``` - -### Setting up the app to work with the Graph Javascript Service Library - -```typescript -const deviceCodeCredentials = new DeviceCodeCredential({ - tenantId: "b61f9af1-d6cf-4cc0-a6f6-befb38bc00ed", - clientId: "bde251a6-0ef9-42a8-a40b-9ad9bb594b2c", -}); - -const scopes = ["User.Read", "Mail.Send"]; - -const graphClient = Client.init({ - authenticationTokenProvider: new AzureIdentityAuthenticationProvider(deviceCodeCredentials, scopes), -}); -``` - -### Calling Microsoft Graph via the Graph Javascript Service Library - -The core value of the Microsoft Graph Javascript Service Library is the availability of the Fluent API. This provides developers with typechecking and discoverability when building on Microsoft Graph. This Fluent API is made available via the Request Builder concept and highlights the full spectrum of capabilities on Microsoft Graph. - -Models are also available in this package and should reflect the underlying version of Graph we are targeting. Developers using our types should do it in a way that will be familiar to how they are used to with other SDKs and APIs. We should provide an easy-to-use model that feels natural in the Javascript world. This means we should not be forcing developers to use Classes and / or other structures that will make their code less natural to them. - -We have an open issue about the above topic that can be followed here : [TypeScript - Use of interface models instead of class models](https://github.com/microsoft/kiota/issues/1013) - -```typescript -const me: User | undefined = await getMe(); -const meRaw: User | undefined = await getMeRaw(); -await sendMail(); -await sendMailRaw(); - -// The types returned by the fluent API should be the same as the .api() area. It should also be the same (or at least very similar) as the current @microsoft/microsoft-graph-types to offer seamless migration. -async function getMe(): Promise { - return await graphClient.me.get(); -} - -// Allowing raw calls (using the .api() method instead of the full fluent API) is important for migration purposes and cases we don't know the resource beforehands (thinking Graph Explorer, mgt-get, etc.) -async function getMeRaw(): Promise { - return await graphClient.api("/me").get(); -} - -// Sending an email via the fluent API -async function sendMail(): Promise { - const message: Message = { - subject: "Hello Graph TypeScript SDK!", - body: { - contentType: BodyType.Html, - content: "Hello Graph TypeScript SDK!", - }, - toRecipients: [ - { - emailAddress: { - address: "admin@m365x263716.onmicrosoft.com", - }, - }, - ], - }; - - return await client.me.sendMail.post(message); -} - -// Sending the email via the .api() method -async function sendMailRaw(): Promise { - const message: Message = { - subject: "Hello Graph TypeScript SDK!", - body: { - contentType: BodyType.Html, - content: "Hello Graph TypeScript SDK!", - }, - toRecipients: [ - { - emailAddress: { - address: "admin@m365x263716.onmicrosoft.com", - }, - }, - ], - }; - - return await client.api("/me/sendMail").post({ - message: message, - }); -} -``` - -## NodeJS e2e using the Core library - -### Concept - -This example brings very similar concepts, but utilizing only the core library. That means that as a developer, we only care about the core capabilities (authentication, serialization, etc.) but we don't need / want the fluent API. This also highlights that types are still important in this case (similarly to how they were important with the v3 of the SDK using our Typings). - -### Install the Microsoft Graph Javascript Core SDK - -The Microsoft Graph Javascript Core SDK includes the following packages: - -- `@microsoft/msgraph-sdk-javascript-core` ([npm](https://www.npmjs.com/package/@microsoft/msgraph-sdk-javascript))- The core library for making calls to Microsoft Graph. -- `@microsoft/msgraph-sdk-javascript-type` ([npm](https://www.npmjs.com/package/@microsoft/msgraph-sdk-javascript-type)) - The Typescript types for the Microsoft Graph entities. - -You can use [npm](https://www.npmjs.com) to install the Microsoft Graph Javascript SDK: - -```Shell -npm install @microsoft/msgraph-sdk-javascript-core --save -npm install @microsoft/msgraph-sdk-javascript-types --save-dev -``` - -As a developer, the only package you really need is the `@microsoft/msgraph-sdk-javascript-core` one. This will deliver the expected capabilities (authentication, middlewares, tasks, etc.) and should be used in a comprehensive way for existing NodeJS developers. The types are recommended but optional. - -### Importing the right functionalities from the Graph Javascript Core SDK - -```typescript -import { Client } from "@microsoft/msgraph-sdk-javascript-core"; -import { User, Message, BodyType } from "@microsoft/msgraph-sdk-javascript-core-types"; -import { AzureIdentityAuthenticationProvider } from "@microsoft/msgraph-sdk-javascript-core/authentication"; -import { DeviceCodeCredential } from "@azure/identity"; -``` - -### Setting up the app to work with the Graph Javascript Core SDK - -There should not be a difference between using the core library and the service library. The setup code should remain the same to deliver a simplified developer experience. - -```typescript -const deviceCodeCredentials = new DeviceCodeCredential({ - tenantId: "b61f9af1-d6cf-4cc0-a6f6-befb38bc00ed", - clientId: "bde251a6-0ef9-42a8-a40b-9ad9bb594b2c", -}); - -const scopes = ["User.Read", "Mail.Send"]; - -const graphClient = Client.init({ - authenticationTokenProvider: new AzureIdentityAuthenticationProvider(deviceCodeCredentials, scopes), -}); -``` - -### Calling Microsoft Graph via the Graph Javascript Core SDK - -Calling the API should be done in a familiar way and should most importantly return the same models that the service library returns. That means that I can build on top of either modules without the need to redefine the types that I'll be receiving back from the API. - -Developers using our types should do it in a way that will be familiar to how they are used to with other SDKs and APIs. We should provide an easy-to-use model that feels natural in the Javascript world. This means we should not be forcing developers to use Classes and / or other structures that will make their code less natural to them. - -We have an open issue about the above topic that can be followed here : [TypeScript - Use of interface models instead of class models](https://github.com/microsoft/kiota/issues/1013) - -```typescript -const me: User = await getMe(); -await sendMail(); - -async function getMe(): Promise { - return await graphClient.api("/me").get(); -} - -async function sendMail(): Promise { - const message: Message = { - subject: "Hello Graph TypeScript SDK!", - body: { - contentType: BodyType.Html, - content: "Hello Graph TypeScript SDK!", - }, - toRecipients: [ - { - emailAddress: { - address: "admin@m365x263716.onmicrosoft.com", - }, - }, - ], - }; - - return await client.api("/me/sendMail").post({ - message: message, - }); -} -``` diff --git a/design/service-library.md b/design/service-library.md new file mode 100644 index 000000000..72e783ddf --- /dev/null +++ b/design/service-library.md @@ -0,0 +1,190 @@ +# End-to-end usage of kiota-generated API Clients in JavaScript + +While working with the Kiota + JavaScript teams, it became clear that we needed more context and provide a better vision on how we should be using a kiota-generated API Client. This design document aims at providing clarity and a better understanding on how developers will be using our API Client and the underlying kiota packages. + +## Status + +| Date | Version | Author | Status | +| ------------------- | ------- | ---------------- | ------ | +| December 14th, 2022 | v0.3 | Sébastien Levert | Draft | +| February 15th, 2022 | v0.2 | Sébastien Levert | Draft | +| January 17th, 2022 | v0.1 | Sébastien Levert | Draft | + +## Constraints + +Before we jump into the end-to-end walk-through, it's important to set some constraints. + +| Type | Environment | Description | +| --------- | ----------- | ------------------------------------------------------------------------------------------------- | +| Platforms | Node | Current and 2 Previous LTS (16 / 18) | +| Platforms | Web | Edge, Chrome, Firefox and Safari (Latest released version + immediate previous version) | +| Modules | Node | ESM2019 + CJS | +| Modules | Web | ESM2019 | +| Types | All | Typings / Models should be available for both the core and the service libraries for Graph models | + +## NodeJS end-to-end using the Service library + +### Concept + +This example is utilizing both the core and the service library. That means that as a developer, we want the full fluent API, allowing me discover APIs via the intellisence. Because the service library leverages the core library, we also want to highlight that we can leverage the core components directly (like the `.api()` method). + +### Install the Microsoft Graph JavaScript Service Library + +There will be two versions of the service library for the Graph JavaScript API Client. The default one will bring the representation of the v1.0 of Microsoft Graph. The second one will bring the representation of the beta of Microsoft Graph. This will be the only difference between these two libraries, as all the handcrafted code (delivering authentication, middlewares, tasks, etc.) will happen in the core library. + +The Microsoft Graph JavaScript Service Library includes the following packages: + +- `@microsoft/microsoft-graph-client` ([npm](https://www.npmjs.com/package/@microsoft/microsoft-graph-client)) - The service library for making fluent calls to Microsoft Graph v1.0. +- `@microsoft/microsoft-graph-client-beta` ([npm](https://www.npmjs.com/package/@microsoft/microsoft-graph-client-beta)) - The service library for making fluent calls to Microsoft Graph beta. + +You can use [npm](https://www.npmjs.com) to install the Microsoft Graph JavaScript Service Library: + +```shell +npm install @microsoft/microsoft-graph-client --save +npm install @microsoft/kiota-authentication-azure --save +npm install @azure/identity --save +``` + +### Importing the right functionalities from the Graph JavaScript Service Library + +```typescript +import { Client } from "@microsoft/microsoft-graph-client"; +import { User, Message, BodyType } from "@microsoft/microsoft-graph-client/models"; +import { AzureIdentityAuthenticationProvider } from "@microsoft/kiota-authentication-azure"; +import { DeviceCodeCredential } from "@azure/identity"; +``` + +### Setting up the app to work with the Graph JavaScript Service Library + +```typescript +const deviceCodeCredentials = new DeviceCodeCredential({ + tenantId: "b61f9af1-d6cf-4cc0-a6f6-befb38bc00ed", + clientId: "bde251a6-0ef9-42a8-a40b-9ad9bb594b2c", +}); + +const scopes = ["User.Read", "Mail.Send"]; + +const graphClient = Client.init({ + authenticationTokenProvider: new AzureIdentityAuthenticationProvider(deviceCodeCredentials, scopes), +}); +``` + +### Calling Microsoft Graph via the Graph JavaScript Service Library + +The core value of the Microsoft Graph JavaScript Service Library is the availability of the chained request builder pattern (fluent API). This provides developers with typechecking and discoverability when building on Microsoft Graph. This would highlight the full spectrum of capabilities on Microsoft Graph directly in the API Client. + +Models are also available in this package and should reflect the underlying version of Graph we are targeting. Developers using our types should do it in a way that will be familiar to how they are used to with other API Clients and APIs. We should provide an easy-to-use model that feels natural in the JavaScript world. This means we should not be forcing developers to use Classes and / or other structures that will make their code less natural to them. + +Because of the richness of the Graph APIs, we are making a decision to require developers to selectively import the areas of Graph they care about. This will provide a lightweight bundle size while still offering a good developer experience. + +### Selective Imports of the Graph areas needed + +To offer a bundle size that fair to the developer, we are using a selective imports strategy. This strategy enables developers to bring only the endpoints they need from Graph. Developers would only see the root paths of Graph when using the API Client by default, and would need to import additional path with selective imports. + +#### Using the service library without any selective imports + +> ❌ **Fails**
+> This example does not work because `usersById().directReports` is not available at the root of the Graph Client + +```typescript +const directReports = await graphClient.usersById("ab677c1b-50c6-4013-aa9f-792ed42c59c8").directReports.get(); +``` + +> ✅ **Succeeds**
+> This example succeeds because `me` is at the root of the Graph Client + +```typescript +const me = await graphClient.me.get(); +``` +> ✅ **Succeeds**
+> This example succeeds because `users` is at the root of the Graph Client + +```typescript +const users = await graphClient.users.get(); +``` + +#### Using the service library with selective imports + +> ❌ **Fails**
+> This example fails because `@microsoft/microsoft-graph-client/users/item` is not imported and therefore not available on the Graph Client + +```typescript +import "@microsoft/microsoft-graph-client/users"; +const directReports = await graphClient.usersById("ab677c1b-50c6-4013-aa9f-792ed42c59c8").directReports.get(); +``` + +> ✅ **Succeeds**
+> This example succeeds because `/users/item` is imported, making it available on the Graph Client + +```typescript +import "@microsoft/microsoft-graph-client/users/item"; +const directReports = await graphClient.usersById("ab677c1b-50c6-4013-aa9f-792ed42c59c8").directReports.get(); +const extensions = await graphClient.usersById("ab677c1b-50c6-4013-aa9f-792ed42c59c8").extensions.get(); +const extensions = await graphClient.usersById("ab677c1b-50c6-4013-aa9f-792ed42c59c8").extensionsById("85147e97-ed89-4799-b5b8-8d35a9204604").get(); +const joinedTeams = await graphClient.me.joinedTeams.get(); +``` + +> ✅ **Succeeds**
+> This example succeeds because `/users` is imported, making it available at the root of the Graph Client + +```typescript +import "@microsoft/microsoft-graph-client/me"; +import "@microsoft/microsoft-graph-client/me/joinedTeams"; +const joinedTeams = await graphClient.me.joinedTeams.get(); +``` + +> ✅ **Succeeds**
+> This example succeeds because `/me` is imported, making it available at the root of the Graph Client + +```typescript +import "@microsoft/microsoft-graph-client/me"; +import "@microsoft/microsoft-graph-client/me/insights"; +import "@microsoft/microsoft-graph-client/me/insights/trending"; +const trending = await graphClient.me.insights.trending.get(); +``` + +#### In-Context Help + +To provide as much context as possible, all modules that are augmented should provide remarks on how to obtain the child resources they contain. This would be added as part of the attached comment block and visible in the developers IDEs. + +![Child resources remarks](assets/service-library/child-resources-remarks.png) + +### Use Request Configuration + +Using request configuration allows developers to personalize their requests with different configuration options. The following snippets demonstrate how developers should be using the API Client. + +```typescript +// Specifying only Query Parameters +const users = await graphClient.users.get({ + queryParameters: { + count: true + } +}); +``` + +```typescript +// Specifying Query Parameters and Headers +const users = await graphClient.users.get({ + queryParameters: { + count: true, + filter: "endsWith(mail, 'microsoft.com')", + orderby: "displayName", + select: "id,displayName,email", + search: 'displayName:room' + }, + headers: { + ConsistencyLevel: ["Eventual"] + } +}); +``` + +```typescript +// Specifying Middleware Options +graphClient.usersById("ab677c1b-50c6-4013-aa9f-792ed42c59c8").patch({ + displayName: "Megan Bowen" +}, { + options: [ + new RetryHandlerOptions({ maxRetries: 10 }) + ] +}); +``` \ No newline at end of file