-
Notifications
You must be signed in to change notification settings - Fork 216
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
feature/request builders proxy #3938
Conversation
5cc4b5a
to
214a0b4
Compare
@andrueastman another big PR for you to review if you have some available time. |
37c1ef0
to
e7e8304
Compare
I forgot to paste my feedback on this PR before the holidays:
Webpack stats with kiota 1.9.1 vs. this PR:
Full bundle size when using Graph. |
ba9116b
to
2b26a0e
Compare
on the results@sebastien I'm extremely surprised by those results. Especially the fact the bundle is the same exact size here given we've reduced the amount of code locations in the generated code by half. I could understand we didn't achieve a 50% benefit, but no change at all seems suspicious. I'll try to run a couple of comparisons on my end to see whether I get the same results or not. on additional things we might want to exploreQuery parametersFor query parameters mappings we could change from this const MessagesRequestBuilderGetQueryParametersMapper: Record<string, string> = {
"count": "%24count",
"expand": "%24expand",
"filter": "%24filter",
"orderby": "%24orderby",
"search": "%24search",
"select": "%24select",
"skip": "%24skip",
"top": "%24top",
}; to that export function MessagesRequestBuilderGetQueryParametersMapper(source: MessagesRequestBuilderGetQueryParameters): Record<string, unknown> {
return {
"%24count": source.count,
"%24expand": source.expand,
"%24filter": source.filter,
"%24orderby": source.orderby,
"%24search": source.search,
"%24select": source.select,
"%24skip": source.skip,
"%24top": source.top,
};
} The idea being we'll have fewer strings, but more code locations (35 vs 108). I'm not sure this will result in gain since strings usually compress well. But it might be worth tryings Request metadataCurrently looks like this export const MessagesRequestBuilderRequestsMetadata: Record<string, RequestMetadata> = {
"get": {
responseBodyContentType: "application/json",
errorMappings: {
"4XX": createODataErrorFromDiscriminatorValue,
"5XX": createODataErrorFromDiscriminatorValue,
} as Record<string, ParsableFactory<Parsable>>,
adapterMethodName: "sendAsync",
responseBodyFactory: createMessageCollectionResponseFromDiscriminatorValue,
queryParametersMapper: MessagesRequestBuilderGetQueryParametersMapper,
},
"post": {
responseBodyContentType: "application/json",
errorMappings: {
"4XX": createODataErrorFromDiscriminatorValue,
"5XX": createODataErrorFromDiscriminatorValue,
} as Record<string, ParsableFactory<Parsable>>,
adapterMethodName: "sendAsync",
responseBodyFactory: createMessageFromDiscriminatorValue,
requestBodyContentType: "application/json",
requestBodySerializer: serializeMessage,
requestInformationContentSetMethod: "setContentFromParsable",
},
}; We could replace verbs (get/post/...) by an enum, I'm not sure how much strings vs import of an enum is going to make an impact. My guess is that it'll be beneficial to segments with multiple operations, detrimental to single operations. On tree shakingAfter further inspection, our client is still a big tree of the API surface and all its operations. It should be lighter since we have about half the code locations, but it'll still be hard to tree shake at this point. On the initial FHL POCHere are the reasons why the FHL project is much lighter:
|
I'll push additional optimizations soon, but first I wanted to establish a baseline.
|
There are additional optimizations we could implement (not graph specific):
There are additional optimizations we could implement (graph specific):
More investigations to follow |
7bf81d7
to
b420de2
Compare
update: the current form (aside from maybe deduplicating the error mappings as it's a low hanging fruit) should be sufficient enough since we pivoted to splitting the full service library across multiple packages (one for models and empty service client + one per root path segment for fluent API with modular augmentation). Here are the results of an early investigation:
|
…t for interfaces Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
- implements request metadata constant Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
…e the wrong name in typescript Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Co-authored-by: Eastman <andrueastman@users.noreply.github.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
…adata Signed-off-by: Vincent Biret <vibiret@microsoft.com>
- removes strings for typescript navigation metadata Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
b420de2
to
306a4cf
Compare
@andrueastman this is ready for final review and merge :) |
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Quality Gate passedThe SonarCloud Quality Gate passed, but some issues were introduced. 3 New issues |
fixes #3642