Saner routing for growing Flask applications
flask-via.soon.build
Saner routing for growing Flask applications
1–10 of 21 posts
Re: Saner routing for growing Flask applications
#2Re: Saner routing for growing Flask applications
#3I'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.
Re: Saner routing for growing Flask applications
#4I'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?
Re: Saner routing for growing Flask applications
#5Am I the only one who thinks that routes should be defined near views, just like default Flask does?
Re: Saner routing for growing Flask applications
#6How is this different to http://werkzeug.pocoo.org/docs/routing/
Re: Saner routing for growing Flask applications
#7Am I the only one who thinks that routes should be defined near views, just like default Flask does?
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.
Re: Saner routing for growing Flask applications
#8Am I the only one who thinks that routes should be defined near views, just like default Flask does?
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?
Re: Saner routing for growing Flask applications
#9Am I the only one who thinks that routes should be defined near views, just like default Flask does?
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?
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.
Re: Saner routing for growing Flask applications
#10How is this different to http://werkzeug.pocoo.org/docs/routing/
Flask, under the hood, uses Werkzeug routing. Basically, this is a wrapper over Werkzeug, just like Flask routing is.