Generate per-operation ServiceHandlers #304
Conversation
| writeSerdeContextBase(writer); | ||
| writeHandleFunction(writer); |
There was a problem hiding this comment.
Can't these be somewhere shared?
There was a problem hiding this comment.
Do you mean written to one TS file that's shared between the two? Seemed more complicated than it was worth to me at the time. Besides, the duplicates should always be tree-shaken out, right?
| writer.openBlock("input = await serializer.deserialize(request, {", "});", () -> { | ||
| writer.write("endpoint: () => Promise.resolve(request), ...this.serdeContextBase"); | ||
| }); | ||
| static void generateOperationHandler(SymbolProvider symbolProvider, |
There was a problem hiding this comment.
Shouldn't this be in the operation generator
There was a problem hiding this comment.
In my head ServerGenerator was for anything related to the higher-level server abstractions -- meaning not deserialization. I could rip this apart and move some of it to ServiceGenerator and some of it to OperationGenerator.
There was a problem hiding this comment.
Well there's the unfortunately named ServerCommandGenerator
There was a problem hiding this comment.
Yeah, that's mostly serde right? Maybe the distinction isn't worth it, idk.
| operation.getId().getName(), | ||
| () -> { | ||
| HttpTrait httpTrait = operation.expectTrait(HttpTrait.class); | ||
| generateUriSpec(context, operation, httpTrait); |
There was a problem hiding this comment.
maybe this is overkill, but could this be shared so it's only defined once?
There was a problem hiding this comment.
Do you mean the UriSpec is only defined in TS once? These end up in different files, so I'd have to have a uri specs file, and generate and export a unique const per spec. Or generate a UriSpec factory that can take in a service and operation and export that. Does not seem worth the upside to me at the moment.
There was a problem hiding this comment.
Yeah I meant define it once in the operation's file and then import it in the service. Doesn't really matter since it's pointless outside of the context of the mux anyway
...escript-codegen/src/main/java/software/amazon/smithy/typescript/codegen/ServerGenerator.java
Outdated
Show resolved
Hide resolved
...n/src/main/java/software/amazon/smithy/typescript/codegen/integration/ProtocolGenerator.java
Outdated
Show resolved
Hide resolved
This lets service developers choose between a single lambda function per operation, or one lambda function that handles all operations, depending on their preferences.
adamthom-amzn
force-pushed
the
operation-per-lambda
branch
from
c5d7032 to
c767ac3
Compare
This lets service developers choose between a single lambda function per operation, or one lambda function that handles all operations, depending on their preferences.
This were missed when 0.2.0 was published Commit: aws/aws-sdk-js-v3@137505b
This were missed when 0.2.0 was published Commit: aws/aws-sdk-js-v3@f55b65e
Description of changes:
This lets service developers choose between a single lambda function per
operation, or one lambda function that handles all operations, depending on
their preferences.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.