

Saner routing for growing Flask applications - krak3n_
http://flask-via.soon.build/

======
gecko
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
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.

------
manish_gill
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'])

------
zepolen
How is this different to
[http://werkzeug.pocoo.org/docs/routing/](http://werkzeug.pocoo.org/docs/routing/)

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

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

~~~
jessaustin
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
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.

------
rpicard
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?

------
michaelmior
GitHub: [https://github.com/thisissoon/Flask-
Via](https://github.com/thisissoon/Flask-Via)

------
piqufoh
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
Are you aware of Blueprints?

~~~
bsaul
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
Do you have any good pointers to reference API implementations in Flask that
you really like?

~~~
lukasm
[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)

