|
|
|
|
|
by nicce
785 days ago
|
|
I am still trialing Smithy, but as far as I understand, the code which is generated by Smithy, generates suitable abstractions and you never modify this code yourself. It leaves the middleware library selection for the user, and with middleware you can do whatever more complex operations you need. TypeScript server overview: https://smithy.io/2.0/ts-ssdk/introduction.html > This execution flow allows the service developer to choose not only their endpoint, but the programming model of their service. For instance, all of the shim conversion and handler invocation can be refactored into a convenience method, or the service developer could choose to incorporate their favorite open source middleware library, of which the server SDK would simply be one layer. It also allows open-ended request preprocessing and response postprocessing to happen independent of Smithy. For instance, a developer could add support for request or response compression, or a custom authentication and authorization framework could be plugged into the application before the server SDK is invoked, without having to fight against a more heavyweight abstraction. The Service type itself also seems to make it possible to define quite complex logic: https://smithy.io/2.0/spec/service-types.html |
|