[WIP] Client generator #64
Conversation
|
This is reviewable, but the design is still very much open to change if the feedback indicates as much. /cc @chrisradek @AllanFly120 |
|
For reference, a sender generated from the Lambda model can be viewed here: https://paste.amazon.com/show/eskewj/1510768271 Imports from defaults are missing, and I spotted a few typos at first glance, but it's generally working as expected. |
|
With the latest commits, a sender looks like this: https://paste.amazon.com/show/eskewj/1510774912 |
|
Overall, I think the approach for customizations is reasonable. I've been trying to think up how we can simplify things (write a tool that generates the customization definitions?) but nothing I've come up with makes things easier. I do have one question I haven't been able to figure out: what is the point for the ResolvableConfiguration? I understand it provides type-safety for additional configuration properties, but I don't quite understand when you would put something there. |
|
The |
… another computer
| @@ -0,0 +1,21 @@ | |||
| { | |||
| "name": "@aws/config-resolver", | |||
| "version": "0.0.1", | |||
There was a problem hiding this comment.
Just to make sure I understand correctly, this package is for resolving the configuration - based on a definition - during runtime, not build, right?
| if (defaultValue !== undefined) { | ||
| input = defaultValue; | ||
| } else if (defaultProvider) { | ||
| input = defaultProvider(out); |
There was a problem hiding this comment.
Why does out need to be provided to the defaultProvider? Would we expect out to be mutated within the provider?
There was a problem hiding this comment.
out isn't expected to be mutated by the default provider, but the provider has access to configuration that has already been resolved. An example of when this is done is with serializers, whose constructors need access to base64 and utf8 encoders
There was a problem hiding this comment.
That makes sense, but is that happening how we'd expect? It looks like out is an empty object to start with, and gets populated as properties are iterated over. What happens if we get to the serializer property before we've encountered the base64 or utf8 encoder properties?
There was a problem hiding this comment.
Order is significant, and properties are only allowed to depend on previously-resolved properties. That's the only way we can ensure defaults have been injected and normalization has occurred. (That's why the base64 and utf8 converters are resolved before serializers and parsers.)
* Add signing middleware * WIP commit -- macbook keyboard nonresponsive, so transferring work to another computer * WIP commit - switching back to the macbook * Add a configuration resolver package * Finish first-draft sender generator (reviewable but still WIP) * Ensure generator can be run even if installed somewhere * Improve naming of build-time configuration types * Add applicator for signer * Ensure empty lines are not indented in nested sections * Rebase over master to incoporate HTTP handlers * Add a destructor to HttpHandler and call it in service clients * Ensure index file is generated for model packages * Add preliminary ClientGenerator class
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread. |
The generator for clients is still a WIP, but the current commits add some important type definitions.