Alternate endpoint support.

[bedge]

I understand that this is targeted at lambda, which is stateless. We have a need to keep a large model in memory, ~1GB deserialized from s3, so doing so for each API call is not practical so lambda is not an option, but the rest of the framework is ideal.

Coupling the API GW front-end to an ec2 instance backed endpoint, rather than a lambda service, incurs a large amount of additional wiring for what is a variation on the back-end implementation, ie: lambda vs an http endpoint.

This framework would be very useful for non-lambda services tied to the API GW as well.

[sdole]

Great point. Can this be done by creating an api endpoint as required through console or through other means (cli/api). So, dont even use chalice, just create an api gateway configuration and point it to your custom ec2 server endpoint. ?

[bedge]

Yes, there's many ways of wiring an ec2 instance to an API GW, however there is much more labor involved. Chalice makes most of this seamless.
You need to explicitly deal with authentication, request routing/mapping, tooling integration (swagger/python/AWS APIs), etc. All things that are handled by chalice. Ideally I'd like to be able to use something like flask-restplus for the API definition and leverage the same economy of glue code as shown by the chalice/lambda example. There's nothing like chalice, or any other API GW/python integration framework available for the API GW with an ec2 backend. Everyone appears to be focusing on the stateless model, which unfortunately doesn't work for all cases.

[jamesls]

I'm interested to hear more, but I suspect this might be out of scope for chalice for now.

Could someone suggest what the API/workflow would look like for an EC2 backend? Let's say I wanted to set up a single route /foo that routed to an ec2 backend. What are the ideal steps to set this up?

[bedge]

The main difference between Lambda and ec2 services on the API GW are how the GW dispatches the incoming API request to the service provider, to either a lambda vs ec2 endpoint. It's this additional plumbing that one needs to setup for ec2 endpoints that would be nice to streamline as Chalice has done for the lambda case. These can be broken down into 2 main segments, authentication/roles, and implementation. I'm still working through my own use case for the ec2 authentication aspect, but I know one issue is the certificate chain. As for the implementation aspect, lambda & Chalice re-deploy the lambda code, with ec2, one could use codedeploy to streamline the updates of the back end implemenation. This is all still WIP for me, but I wanted to throw out my thoughts to date.

[bedge]

@jamesls To address your question about workflow.

1) Deploy ec2 instance with operational API that supports swagger doc extraction for API Doesn't matter how the ex2 instance gets deployed. Ideally this could allow cloudformation, manual deployment, etc. The chalice tooling wouldn't even have to care. It just needs to know that it's done.

2) Chalice extracts swagger API doc from ec2 instance's endpoint. Provide the ec2 EP as a parameter to chalice. something like: chalice import-api <URL> This extracts the json swagger API definition from the application.

3) Generate the API GW and ec2 EP connections. This is analogous to the chalice deploy command, so for configurations that are ec2 based rather than lambda based, the 'deploy' command uses the extracted swagger json doc rather than the local python lambda code as the source for the API GW structure.

The extraction in 2 and the API generation could be one step.

There's additional metadata that needs to be handled in the ec2 case that's not needed for lambda. The method request/response, integration request/response parameters need some way to pass through from the ec2 service to the API GW configuration. flask-restplus provides some of the medata needed, but may be lacking in the vendor-extension support. One could provide this data in the .chalice/config.json if not present in the swagger vendor extension fields. This would provide the greatest possible support for swagger tooling on the server side as regardless of level of vendor extension support, it could be annotated/overwritten in the chalice config.