librelist archives

Re: [flask] What is a small app?

From:

Dan Jacob

Date:

2010-05-26 @ 13:07

You might also want to refer to the lazy loading pattern for larger projects:

http://flask.pocoo.org/docs/patterns/lazyloading/

On 25 May 2010 17:54, Dan Jacob <danjac354@gmail.com> wrote:
> I'm not sure myself why there still needs to be a "small apps only"
> meme with Flask; I've seen it repeated e.g. in Reddit and it doesn't
> do the framework justice.
>
> The only real restriction was in the early days of the project, using
> the @app.route, because of circular dependencies. With the addition of
> the module API to Flask this restriction no longer exists - you can
> append any number of view modules to your application.
>
> As long as you follow the same good practice as you would for any
> large Python project (i.e. logically breaking up functionality into
> modules and packages) then there is no reason a Flask app cannot be of
> any size.
>
> Also bear in mind that Flask is a really thin, lightweight wrapper
> around Werkzeug, so you can modify (=subclass or patch) if needed and
> use the full power of Werkzeug if you hit a wall.
>
> 16 Django apps and 41 models would count as a large project in my
> book. I can't see any problems modelling this in Flask - you could
> either keep the "apps" structure or split them up into large "models"
> and "views" packages like Pylons or Rails.
>
>
> On 25 May 2010 17:22, Oliver Andrich <oliver@2pxnr.de> wrote:
>> Hi everybody,
>>
>> I have successfully ported a small Django app to Flask, and I really, really
>> enjoy the result. The performance is better, mostly because of using Jinja2
>> instead of Django templates. Or better said, the template rendering is the
>> area of code I have found some performance improvements so far.  The app
>> simply feels snappier now.
>>
>> But I have a another Django app, that would benefit from using Jinja2 for
>> templating and SQLAlchemy as ORM. Not concerning any performance issues,
>> simply because I can modell some things in a different way and because
>> Jinja2 is so neat, when you want to add new filters and so on.
>>
>> As much as I enjoyed the experience when using Flask, the section about the
>> target audience and the explicit reference to small apps makes me feel
>> uneasy at the moment. May be you can help me to clarify this? What would you
>> consider an app, that is too complex for Flask?
>>
>> Reading the docs about larger applications and modules lets me think, that
>> Flask would be a good choice to use for the next version of my app. But
>> there is this section about the target audience. :)
>>
>> My django app is build from 16 self developed apps and 2 external apps.
>> These apps provide 41 model classes and a bunch of views. I can imagine to
>> build the ORM stuff with SQLAlchemy and the rest with Flask using models. Is
>> this a large app? A medium app? A small app? Is this beyond the scope of
>> Flask?
>>
>> Hope you can help me with that.
>>
>> Best regards,
>> Oliver
>>
>>
>>
>

Dan,

thanks for the pointer and many thanks for the mail yesterday. I am not
sure, if the lazy loading pattern is required in my project, but I will keep
it in mind. Honestly, one of the intriguing features of Flask is the
@app.route decorator for me. Concerning a centralized url mapping (or app
based url mapping): Been there, done it. This is one part of my Django app,
that I found really annoying at least. As of today I started proting my
larger Django app to Flask just to learn something more about it.

Best regards,
Oliver

2010/5/26 Dan Jacob <danjac354@gmail.com>

> You might also want to refer to the lazy loading pattern for larger
> projects:
>
> http://flask.pocoo.org/docs/patterns/lazyloading/
>
> On 25 May 2010 17:54, Dan Jacob <danjac354@gmail.com> wrote:
> > I'm not sure myself why there still needs to be a "small apps only"
> > meme with Flask; I've seen it repeated e.g. in Reddit and it doesn't
> > do the framework justice.
> >
> > The only real restriction was in the early days of the project, using
> > the @app.route, because of circular dependencies. With the addition of
> > the module API to Flask this restriction no longer exists - you can
> > append any number of view modules to your application.
> >
> > As long as you follow the same good practice as you would for any
> > large Python project (i.e. logically breaking up functionality into
> > modules and packages) then there is no reason a Flask app cannot be of
> > any size.
> >
> > Also bear in mind that Flask is a really thin, lightweight wrapper
> > around Werkzeug, so you can modify (=subclass or patch) if needed and
> > use the full power of Werkzeug if you hit a wall.
> >
> > 16 Django apps and 41 models would count as a large project in my
> > book. I can't see any problems modelling this in Flask - you could
> > either keep the "apps" structure or split them up into large "models"
> > and "views" packages like Pylons or Rails.
> >
> >
> >
>