Mention Zappa in the README

[Miserlou]

How does the Python Serverless Microframework for AWS compare to other similar frameworks?

Given that Zappa has already done this and more for many months, and that we've actually talked about this, it'd be nice to at least be mentioned in the similar frameworks section. We're a very similar framework that's more mature and more featureful. I do wish that you would have told us that you would be releasing an official AWS competitor to Zappa when we spoke so that we could have avoided so much duplication of effort.

[jamesls]

Hi, thanks for reaching out.

One of the things I’m realizing is that while the announcement blog post and the README stress the “up and running quickly” part of the framework, we don’t actually have anything that dives into the design goals of the project and what I’m hoping to accomplish. I just wanted to share some of the thoughts I had about this project to help clarify things. (I’ll probably move this somewhere in the docs).

On a technical level, one of the biggest differences is that we do not (and at least I don’t plan to) support WSGI. That’s not to say it doesn’t make sense to support WSGI, or that there shouldn’t be a framework that pairs API Gateway and Lambda with WSGI. It’s just that this is not a goal of this project.

I think that distinction makes a difference in what the projects are trying to accomplish. Supporting WSGI means that you don’t actually need to provide a new framework. Someone can simply pick their favorite WSGI compliant framework (which is basically all python web frameworks these days), or even a pre-existing app they’ve written, and deploy it to API Gateway and Lambda. I think that’s powerful.

This project, on the other hand, is trying to explore what a minimalistic framework would look like that makes writing rest APIs that run on API Gateway and Lambda as streamlined and quick as possible. It has a very narrow focus, and is still very experimental. One part of that is the routing API we expose to app writers. This ended up being a decorator based routing API used by Flask/Bottle, primarily because of the intuitive nature of the API that most developers are familiar with (Flask, Sinatra, Express, Slim, Nancy, etc.).

But that’s also just one aspect of this project. I think there’a also some other interesting ideas that fall in line with the goal of “up and running quickly”. One of the more interesting ones is the auto policy generation which does static analysis on your source code to attempt to generate an IAM policy based on the API calls you make. It’s still very much in the early stages, but I think it has potential, and could open up additional uses cases. It may even be factored out into a separate library if the idea ends up panning out.

Hopefully this clarifies the project. I'd love to discuss this more with you.

[Miserlou]

As I said, Zappa literally already does all of those things, and more, and has for several months. It is also incredibly easy to use, and "just works" out of the box:

In fact, you can obviously see the striking similarities to our README file in your own launch announcement demo. Quite frankly, it seems like AWS has ripped off our project, but nerfed it so that it locks users in to the AWS ecosystem. There are no advantages in using Chalice over Flask + Zappa.

My only point is that it just seems very dishonest to have a section in the README called "How does the Python Serverless Microframework compare to other similar frameworks?" and not mention Zappa.

Please at least mention us in the README? It's the honest thing to do.

[numberoverzero]

My only point is that it just seems very dishonest to have a section in the README called "How does the Python Serverless Microframework compare to other similar frameworks?" and not mention Zappa.

Besides Zappa, are there any other serverless python microframeworks? I'm pretty sure this is the whole category.

---

disclaimer: I stumbled on this through an unrelated issue in one of my projects, tangentially related to lambda. I'm not personally invested, I just think going from wsgi-compliant to flask-ish is a step backwards. And to be fair, it is a preview.

This is a fantastic project, and the very simple configuration options really make it easy to get started quickly. However, scanning the first page of issues makes it clear that people are running into those constraints and in some cases, prohibitively so.

While simplicity and ease of use are great goals, it's not correct to forsake usability in favor of them. It can be easy to forget this when looking at projects like bottle, flask, and requests. They're easy to start using right away, and that makes it easy to miss the deep, extensible systems that underpin each.

Sessions, cookie management, cert bundles, caching, redirects, streaming responses: when you use requests for the first time you probably don't care about any of these. As soon as you need them however, the options are right there. Flask on its own is nice, but it's the ability to create powerful domain-specific extensions that makes it so widely useful. Flask would be a much smaller community if it had stopped at routing, json serialization and some header manipulation.

---

Zappa is exclusively Lambda + Gateway, so it already achieves customer lock-in. It's in production use right now; aside from the press coverage, there are already a number of thorough guides that cover the extensions and configuration that customers are asking about here.

There's a lot of documentation that you'll need to re-write. How do I use this with Let's Encrypt? What about a database? Anything special to use pyenv, or conda? How about pre-compiled dependencies?

It's in the customer's interest to aggressively pull any lessons from Zappa that you can; otherwise you're bound to go through dozens of the same questions, enhancements, bugs. Especially with respect to deviating from WSGI. WSGI was created specifically to avoid these sort of splits. Stepping back from that standard in favor of an almost-flask-but-not-quite framework will cut out a lot of the tools and plugins customers already use.

---

Or, you can use any WSGI-compatible app you like! You probably don't need to change your existing applications ...

This is what matters to most customers that are considering a serverless architecture. There are a lot more asking "how do we migrate off these hosts" than are starting new development. It's a non-starter to ask customer, while bootstrapping on a serverless architecture, to also please rewrite their code and any plugins they use.

[jamesls]

Thanks for the feedback here, both @Miserlou and @numberoverzero.

I do want to clarify something. I have no issue with adding zappa and other frameworks in the README. That section was mostly written with serverless in mind, which was something we were frequently asked. My previous comment in this thread was more meant to spark a discussion about the project and how it relates/compares to other projects.

@numberoverzero, I hear your concerns, and it’s something I’ve thought about quite a bit (and enjoy discussing with others). As you mentioned, it is a preview project, and more specifically an AWS labs project as opposed to going straight to the aws/ org on github. I think there’s still a lot to explore.

This project has several pieces to it:

• the framework, that is, the code that users interact with to write their application
• the adapter code to “make it work” on the backend on which it’s running
• the control plane code to deploy, monitor, update apps, usually some sort of CLI

For me, the part I’m most interested in is the framework part. If you were to create a framework that was specifically tailored for a serverless computing platform, what would it look like? What could you improve? Would there be any difference with existing frameworks? This project is trying to explore that space, and is why it’s in AWS labs, and why we make it clear in the README that this is a preview project.

As you mentioned, the initial feature set we launched with was small. This was intentional. I would rather start with features I know we need (like routing), and let the community a) tell us if this is even interesting b) what features they think this framework should have.

I’ve gone ahead and updated the README. I’m happy to discuss further, I’m in the process of creating a gitter channel. Please feel free to stop by and chat anytime.