Live data from Hacker News

Saner routing for growing Flask applications

flask-via.soon.build

11–20 of 21 posts

Re: Saner routing for growing Flask applications

#12
I'm not clear what Blueprints aren't providing here that the author needs, but aside from that, a slightly bigger point:

I really like Flask, but Flask's entire point is that it's a thin, user-friendly wrapper around Werkzeug. Werkzeug isn't my favorite low-level web framework for Python (that'd be WebOb), but the fact that it is trivial to dive into Werkzeug from Flask is Flask's killer feature: its whole raison d'être is that you can smoothly and cleanly replace Flask with your own application-specific Werkzeug middleware as you grow big.

So I guess the only thing that surprises me somewhat here is that the author has approached this as a way of scaling Flask up, rather than providing a clean way of moving Flask out in a way that eases transition to pure Werkzeug. I know that Flask has gradually been growing in some ways via its extensions, and maybe that is indeed its future. But I still think that Flask is best used as the training wheels to get a small app up quickly, and that gradually removing it as you grow is likely the best course of action. Otherwise, I think you'd likely be much better off using a framework like Django, with all the bells and whistles you need for any normal CRUD app, rather than rolling it all yourself in Flask in the first place.

Re: Saner routing for growing Flask applications

#13
post #4
post #3

I've built and maintain several python webapps including both django and flask apps. The routing in flask is the main reason I don't start large projects in flask. This package looks good, I'll certainly be giving it a try.

Are you aware of Blueprints?

Correct. I built a fairly big api in flask, and managed to get everything properly isolated using blueprints. Nothing to worry on that side for me.

Re: Saner routing for growing Flask applications

#14
I'm personally a fan of defining routes near the views with the good old @app.route() call, but it's great to have a lot of options for people beyond the defaults.

As others have mentioned though, this is very similar to app.add_url_rule. Could you explain how this differs?

Re: Saner routing for growing Flask applications

#15
post #12

I'm not clear what Blueprints aren't providing here that the author needs, but aside from that, a slightly bigger point: I really like Flask, but Flask's entire point is that it's a thin, user-friendly wrapper around Werkzeug. Werkzeug isn't my favorite low-level web framework for Python (that'd be WebOb), but the fact that it is trivial to dive into Werkzeug from Flask is Flask's killer feature: its whole raison d'ê…

The idea that Flask is only good for small apps is naive. Plenty of folks have built large, successful, production level Flask apps. All Flask does is act as the glue between Werkzeug and Jinja2 and give you some nice patterns like the app and request contexts. If you're a decent Python developer you're going to end up writing something very similar if you just start with Werkzeug.

Re: Saner routing for growing Flask applications

#16
post #13
post #4

Earlier quoted context omitted.

Are you aware of Blueprints?

Correct. I built a fairly big api in flask, and managed to get everything properly isolated using blueprints. Nothing to worry on that side for me.

Do you have any good pointers to reference API implementations in Flask that you really like?

Re: Saner routing for growing Flask applications

#17
post #3

I've built and maintain several python webapps including both django and flask apps. The routing in flask is the main reason I don't start large projects in flask. This package looks good, I'll certainly be giving it a try.

What problem occurs as an application grows? I've used both Flask and Django, but have never built a large enough project to have problems with routing.

Re: Saner routing for growing Flask applications

#19
post #5

Am I the only one who thinks that routes should be defined near views, just like default Flask does?

For small apps, urls should definitely be defined near views. For larger apps, I would have to disagree. Here's why: Django's url routing system might be cumbersome when you just want to get going with a few routes. However, it acts as an "index" for all your app's urls when you've got tens (or hundreds) of route definitions. So, instead of opening every view file, you can "tree search" for a specific url path. It is very flexible (which can be a plus and a minus).

Re: Saner routing for growing Flask applications

#20
post #17
post #3

I've built and maintain several python webapps including both django and flask apps. The routing in flask is the main reason I don't start large projects in flask. This package looks good, I'll certainly be giving it a try.

What problem occurs as an application grows? I've used both Flask and Django, but have never built a large enough project to have problems with routing.

The default routing method encourages having the routing definitions ontop of the functions them define them, functions that could get quite big. It's all about coding style really, if you write your program well, it's less of an issue.
Post reply on HN