5 ms·

Saner routing for growing Flask applications

45 points by krak3n_ 12y ago

michaelmior 12y ago
GitHub: https://github.com/thisissoon/Flask-Via https://github.com/thisissoon/Flask-Via
piqufoh 12y ago
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.
- lukasm 12y ago
  Are you aware of Blueprints?
  - bsaul 12y ago
    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.
    - kordless 12y ago
      Do you have any good pointers to reference API implementations in Flask that you really like?
      - lukasm 12y ago
        https://www.youtube.com/watch?v=FGrIyBDQLPg https://www.youtube.com/watch?v=FGrIyBDQLPg http://flaskbook.com/ http://flaskbook.com/ https://github.com/miguelgrinberg/flask-examples https://github.com/miguelgrinberg/flask-examples
- cbau 12y ago
  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.
  - keeperofdakeys 12y ago
    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.
gioi 12y ago
Am I the only one who thinks that routes should be defined near views, just like default Flask does?
- bjoerns 12y ago
  Nope, same here! I personally prefer the routes being near the views as they belong together and most times I can't be bothered looking the route up in a different file like in Django or Rails even. But I guess it all comes down to personal preferences.
- jessaustin 12y ago
  You're not the only one; this is also my experience. However, I'm prepared to believe others' claims that there are drawbacks involved with doing this on "large" apps. I wonder whether they mostly value this "all routes in one place" technique for the purpose of documentation, and perhaps a simple Flask helper function that printed out all registered routes would be just as useful for them?
  - aidos 12y ago
    It already exists. app.url_map contains the mappings from paths to endpoints. Personally I treat the flask web as a really thin layer around my other more complex libraries (the core of the application). I use blueprints to group things together but I still try to make sure each of those is very simple, say - routing, data marshalling and session management - but anything more complex lives somewhere else. Each function inside your views just gets a little data together and proxies it down to the real application. As you say, maybe it gets more complex as the app grows in size, but to me that sounds like the app is trying to do too much. Over time I've learnt that thinking of your app as a 'flask application' (django, rails, whatever) means that it will grow in a way that's hard to maintain later.
- cbau 12y ago
  What is the rationale? It isn't obvious to me that it's better either way.
- rlander 12y ago
zepolen 12y ago
How is this different to http://werkzeug.pocoo.org/docs/routing/ http://werkzeug.pocoo.org/docs/routing/
- gioi 12y ago
  Flask, under the hood, uses Werkzeug routing. Basically, this is a wrapper over Werkzeug, just like Flask routing is.
manish_gill 12y ago
Doesn't flask Already provide methods for this? I have an app in which I create a urls.py and do app.add_url_rule('/endpoint', view_func=views.my_func, methods=['GET', 'POST'])
gecko 12y ago
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.
- mattupstate 12y ago
  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.
rpicard 12y ago
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?

45 points by krak3n_ 12y ago

GitHub: https://github.com/thisissoon/Flask-Via https://github.com/thisissoon/Flask-Via

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.

lukasm 12y ago
Are you aware of Blueprints?
- bsaul 12y ago
  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.
  - kordless 12y ago
    Do you have any good pointers to reference API implementations in Flask that you really like?
    - lukasm 12y ago
      https://www.youtube.com/watch?v=FGrIyBDQLPg https://www.youtube.com/watch?v=FGrIyBDQLPg http://flaskbook.com/ http://flaskbook.com/ https://github.com/miguelgrinberg/flask-examples https://github.com/miguelgrinberg/flask-examples
cbau 12y ago
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.
- keeperofdakeys 12y ago
  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.

gioi 12y ago

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

bjoerns 12y ago
Nope, same here! I personally prefer the routes being near the views as they belong together and most times I can't be bothered looking the route up in a different file like in Django or Rails even. But I guess it all comes down to personal preferences.
jessaustin 12y ago
You're not the only one; this is also my experience. However, I'm prepared to believe others' claims that there are drawbacks involved with doing this on "large" apps. I wonder whether they mostly value this "all routes in one place" technique for the purpose of documentation, and perhaps a simple Flask helper function that printed out all registered routes would be just as useful for them?
- aidos 12y ago
  It already exists. app.url_map contains the mappings from paths to endpoints. Personally I treat the flask web as a really thin layer around my other more complex libraries (the core of the application). I use blueprints to group things together but I still try to make sure each of those is very simple, say - routing, data marshalling and session management - but anything more complex lives somewhere else. Each function inside your views just gets a little data together and proxies it down to the real application. As you say, maybe it gets more complex as the app grows in size, but to me that sounds like the app is trying to do too much. Over time I've learnt that thinking of your app as a 'flask application' (django, rails, whatever) means that it will grow in a way that's hard to maintain later.
cbau 12y ago
What is the rationale? It isn't obvious to me that it's better either way.
rlander 12y ago

zepolen 12y ago

How is this different to http://werkzeug.pocoo.org/docs/routing/ http://werkzeug.pocoo.org/docs/routing/

gioi 12y ago
Flask, under the hood, uses Werkzeug routing. Basically, this is a wrapper over Werkzeug, just like Flask routing is.

manish_gill 12y ago

Doesn't flask Already provide methods for this? I have an app in which I create a urls.py and do app.add_url_rule('/endpoint', view_func=views.my_func, methods=['GET', 'POST'])

gecko 12y ago

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.

mattupstate 12y ago
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.

rpicard 12y ago

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?