Hacker News Reader

Comment by cdnsteve | Hacker News Reader

I think I would have preferred this to be some type of plugin/add-on to Flask rather than a full replacement that now locks me to AWS and is a brand new project without any docs :(

If it was a cli with decorators or something that uses Flask I would feel more comfortable and give it a shot.

View on HN

I've looked into doing this. Flask is too integrated with the WSGI protocol to be easily adapted to this model. It presupposes a number of things about the request and response protocol that are not true in Lambda. You would end up having to write an unwieldy WSGI emulation layer (what Zappa did) and still wouldn't be able to achieve 100% WSGI compatibility, breaking a subset of the plugins.

Most people love Flask because of its beautiful, minimalistic route decorators and hooks. That subset of the API can be easily replicated - Chalice is part of the way there - and I'm hoping it emerges as an API standard, separate from WSGI.

You're not wrong, but there are plenty of examples of using Flash without WSGI. I use Flask-Frozen to generate static sites from the CLI, for example.

You may be right overall, but that's a particularly bad example, as Frozen simply eliminates the "flask" portion that gets deployed to the server in lieu of static files, ergo obviating the need for WSGI altogether.

Serving a Frozen app on lambda means serving static files on lambda, which is very doable, and a very different use case than developing something like an API to be deployed to lambda.

Edit: Re-reading our comments, you may be confusing the difficulty -- it isn't in building the CLI for Flask, it's in getting Flask to be served over lambda. Presumably, the OP could easily re-write the deploy functionality to deploy a flask application, it's just that the flask application is unlikely to work because it defaults to WSGI, which lambda (apparently) does not provide.

https://github.com/Miserlou/Zappa might be more useful to you.

I definitely wouldn't build a business on this for the reasons you mention, but there are still very good use cases. E.g. let's say you have a website where you need to strip metadata from images. That's only two or three lines of code with Pillow, but it might be better opsec to do it elsewhere so that if your app somehow gets pwned you don't have the metadata flowing through your system. But if doing that involved setting up an entirely new webserver then that probably wouldn't make sense, especially since the new server would probably be subject to the same vulnerabilities as the original.

Hopefully the Flask team will whip something like that up.

I also want to see this for Django.

Reply on news.ycombinator.com