Hacker News Reader

Comment by jxub | Hacker News Reader

This is epic. In theory now from V1 onwards it should be easier to convince people at big serious corps to use Flask as it cuts down a lot of Django bloat especially for smaller applications, microservices and other nimble backends.

View on HN

Hopefully! There's a bad attitude I've noticed about Flask, people don't take it seriously and treat it like a learning tool or a library for quick and dirty hack projects. All because it's simple to learn and free of bullshit and Just Works™. Should lead to the opposite attitude, but nope. People apparently enjoy extra complexity.

I think a lot of criticism is valid. Flask has a lot of bizarre conventions which don't scale well, like stuffing all shared resources into the global context or app-level dicts and using `@route()` decorators all over, for example. And I'm not sure what the benefit is, except that clever feeling one gets when they use decorators or other seemingly magical features unnecessarily and later need to workaround the tight coupling.

Decorators improve dev speed. No need to be constantly switching back and forth between views and urls.py.

Still, sometimes nice to see all in one place.

They only improve speed from an initial "get it working" point of view. That's part of the reason flask is rarely taken seriously as a production solution. Not having natural separation between views and urls is a real PITA for anyone trying to create a long term solution or larger project. For what it's worth, I also hate the argument that bad design increases Dev speed. That's only true until you need find something later, then you have to hunt around instead of having one place to look, wiping out any initial gains. It's false economy.

FYI with flask you don't have to use decorators for routing. You have the option to define all your routs in a single file.

True in a very large project, false on the rest. Congrats on your one-true-way argument. ;)

I'm a professional Python dev, I have no reason to believe that decorators save any time for any size of project. They're harder to reason about for developers of all experience levels and their is no obvious advantage--some argue that the syntax is more pleasant, but I don't perceive an increase in readability; certainly not one that makes up for the increased cognitive burden. The following is super straightforward, testable, and it doesn't depend on globals for shared resources or request state:

    def hello_handler(r: Request) -> Response:
        return Response.ok("Hello!")

    def goodbye_handler(r: Request) -> Response:
        return Response.ok("Goodbye!")

    if __name__ == "__main__":
        router = Router("/")
        router.register_route("/hello/", "GET", hello_handler)
        router.register_route("/goodbye/", "GET", goodbye_handler)

I was thinking more of the fact the are paired with the view. To be honest never gave the fact they are decorators much thought.

There is a similar feeling towards SQLite

You don't have to use the Django "bloat": https://github.com/syntarsus/minimal-django

What's your application server setup like? Is there a standard for this? I tried using UWSGI and Gunicorn with varied results. It was just a pain to setup. I hope things have improved.

I found it pretty easy to set up with Gunicorn and nginx, all running in Docker

Is there any definite tutorial to set it up with Gunicorn and ngnix? I have used gunicorn before but not with ngnix.

Same setup as the other reply. Gunicorn and flask in docker. Works perfectly and is speedy.

Reply on news.ycombinator.com