search

aws / chalice

Python Serverless Microframework for AWS
Apache License 2.0
10.67k stars 1.01k forks source link

Docs request: high-level design justification #154

Closed simonw closed 2 years ago

simonw commented 8 years ago

This isn't intended as a criticism: I like the API design of Chalice a lot. I'd like to better understand why it differed from Flask and Bottle though. Why have a new framework as opposed to building a library that makes deploying flask apps to lambda easy?

I'm a newcomer to AWS lambda so I imagine the answer to this question is based around restrictions inherent to that platform - so personally I would find it very useful if the docs included a "why Chalice" section that explains the higher level design choices.

mnp commented 8 years ago

Did you see the FAQ at the bottom of the Readme? Chalice hit my needs for the reasons there, over Flask.

jamesls commented 8 years ago

Hi Simon, I'll add specifics about flask/bottle vs. chalice to the docs. As @mnp mentions, the FAQ section has a high level overview which is a good starting point.

In the meantime, you're on the right track with your intuition. It's completely reasonable to want integration at the WSGI layer so you can use existing python frameworks with (almost) no changes. With chalice tailored for API gateway and lambda, we can more deeply integrate with the functionality provided by those services. Consider API gateway, we can offload things to API Gateway that are traditionally handled by web frameworks: routing, throttling, authz, CORS, etc. This has a number of benefits and minimizes the amount of time the lambda function runs. By adding routing info to API gateway, we can also leverage feature like swagger exports, SDK generation, etc.

Labeling as documentation.

simonw commented 8 years ago

Nice answer, thanks very much @jamesls