Open robdefeo opened 8 years ago
You are correct, models are currently not supported.
While I agree with you that they can be useful, I'm not really sure how they would fit in with chalice with it's purposefully small scope. I'm open to suggestions if someone has a concrete API for this, but I'm inclined to consider this out of scope.
Thinking of chalice as "flask on lambda" (essentially a web microframework with opinionated deployment automation), I agree this is out-of-scope and would not want to see this in chalice itself. Instead, chalice should ensure it doesn't get in the way of integrating with 3rd-party libs for this, or a separate chalice-api project should tackle this.
Agreed.
How about chalice is responsible for setting the model on Method Request/Response only. Then another complementary library manages creation of Models via some other process.
For example adding in the model assignment here:
https://github.com/awslabs/chalice/blob/master/chalice/deployer.py#L347
would be straightforward vs providing some kind of hook for a third party lib to participate in resource creation.
Keeping 2 different libraries decoupled while managing the same APIG resource seems tricky.
This would be really handy together with the newly added support for request validators feature in the API gateway.
Is there any plan to add model support?
Alternatively if there is no support in chalice, is there a work around people are using to add models to APIs deployed using chalice?
I think models are a good way to have the input and output objects defined in the generated SDK which can be used by 3rd party client developers.
Any update on that? With python typing that could even be automated
@Tharunreddych, while I haven't experimented with this feature specifically, I've always had scripts in the CI/CD pipeline to modify the cloudformation template before deployment so I can support additional features of API Gateway that Chalice hasn't caught up to. I assume you could accomplish something like this by creating request
and response
directories with the models that you use defined as dataclasses. Then if you had some kind of annotation scheme to connect each one to a specific API endpoint, you could write a script to read the dataclass files and add model information to the cloudformation template. It's not perfect, because you would still need to ensure that your annotations are in sync with the actual dataclasses that you're using for each method, but I believe it would accomplish what you're looking for.
Bumping it up a bit. Pydantic has done the majority of work on this part, and it is known to be one of the top two libs in the python world to handle the DTO schemas. It might be a great idea to integrate it or to provide an option to do so.
Currently I can't see that response models are supported, its an important part of the API definition especially if a SDK will be created from it.
It seems sensible to create a new attribute to be able to define the responses and their definitions so they can be stored in the gateway for the use case of creating a meaning full SDK / Swagger file.