4 ms·

I use Django and Flask quite a bit. They are the first two things I go to for building a site. For a small site, usually without a database, I mostly use Flask.

by Apreche 14y ago

I use Django and Flask quite a bit. They are the first two things I go to for building a site. For a small site, usually without a database, I mostly use Flask. For a large site with all the common features like auth and such, I use Django. Yeah, it has its bad points, but that's ok. It's worth suffering through whatever those bad points are because it has one gigantic good point. You don't have to reinvent the wheel. That is the fundamental problem of all micro-frameworks. They are so small they are incomplete. You may not like Django auth, but Flask has NO AUTH. You have to go get a third party auth system, or write your own. That means with Django I can get a site, with auth, up in just a few minutes. With Flask, you have to write a login page for the 1000th time in your life. It may be very simple to do that, but it's even simpler to do nothing at all.

drivebyacct2 14y ago
I think his point is that this: "You have to go get a third party auth system" is a good thing. That way if the auth implementation needs to change, it can more easily if it's loosely coupled to the application.
- anthonyb 14y ago
  Django's auth system is not that hard to hack on if you need to - in most cases you just need to write a custom backend and implement a few methods on it. It's certainly comparable to writing your own, or downloading something and integrating it.
  - Orf_ 14y ago
    I wrote my own to use SQLAlchemy models you define: http://tomforb.es/using-a-custom-sqlalchemy-users-model-with-django http://tomforb.es/using-a-custom-sqlalchemy-users-model-with... Its really not that bad or hard to do at all.
    - anthonyb 14y ago
      But now you have an auth system that's tightly coupled to SQLAlchemy. How is that different from the regular system, other than you're using SQLAlchemy rather than Django's ORM? I'm also finding it hard to think of a use case where you need to authenticate 100 users at once, so your initial rationale (100 separate updates) doesn't really work. Surely you'd use a different tool to populate your database, but Django's ORM for day to day stuff?
      - zzzeek 14y ago
        Pyramid has an auth system not tied to any ORM or persistence system whatsoever: http://pyramid.readthedocs.org/en/latest/tutorials/wiki/authorization.html http://pyramid.readthedocs.org/en/latest/tutorials/wiki/auth... I'd say that's better than anything hardcoded to a fixed database schema. There's a whole world of development that has no interest in using a mediocre, off the shelf database schema in lieu of one that is designed exactly for the problem at hand.
        anthonyb 14y ago
        Er, that looks pretty hideous to me. I guess the idea is that Pyramid exposes a lot of the internals so that you can tweak it, but what's going on in that code is completely lost in the noise. From all of the hits that I can see on Stack Overflow, I'm not the only one who finds it hard to understand. Not to mention that it completely punts on adding any sort of persistence for user models or password hashing. I stopped trying to figure out what was going on when I realised that headers = remember(request, login) actually returns the raw headers as a list of strings, and you need to feed them manually back into the response. Compare to Django's login, which is a lot clearer, even though it includes all of the things that the Pyramid version skips over: https://docs.djangoproject.com/en/dev/topics/auth/#django.contrib.auth.login https://docs.djangoproject.com/en/dev/topics/auth/#django.co...
        hysan 14y ago
        Well that's cause the Pyramid Auth API is admitted by the authors to be overly complex. They did a post mortem here and you can read about some of the mistakes they made when designing the API: http://plope.com/pyramid_auth_design_api_postmortem http://plope.com/pyramid_auth_design_api_postmortem The most relevant line to take away from their post mortem is this: "Unfortunately, when designing a framework, you get exactly one shot at creating "the right" API. In this case, we didn't." So even with a decoupled API, if the design doesn't fit your needs or is too cumbersome to use, you will still need to find a third party solution or hack the core code. Both of which, as mentioned by others, are possible in Django.
- run4yourlives 14y ago
  So basically, you're going to do more work now because it might pay off in the future under certain circumstances? Talk about solving problems you don't have yet. There may be a very good reason for using a third party anything, but to suggest that this is always the "right thing to do" is ludicrous.
megaman821 14y ago
I had a simple Flask app that need an auth so I wrote my own and I wouldn't quite call it simple. There are so many security concerns. What password hashing algorithm to use (PBKDF2, bcrypt, scrypt, etc). Even the password reset mechanism can be an attack vector if one-time login url is generated poorly and an attacker can generate a large volume of password reset requests.
zby 14y ago
You can also have an AUTH library coded against an interface, a protocol - and then use it with may different frameworks. I am convinced that this can be made practical if you choose the interfaces carefully. I have actually coded an auth lib against the PSGI interface (in Perl it is an equivalent of WSGI) plus a few virtual functions to be implemented in subclasses as connection to the storage database: https://github.com/zby/Plack-Middleware-Auth-Form https://github.com/zby/Plack-Middleware-Auth-Form
zby 14y ago
Why web frameworks tend to grow to become such unwieldy beasts? Most of the web frameworks I know tend to do at least two things - the web stuff plus creation and initialization of all other components. This means that the framework is coupled with all of these components and this is the root of all evil in web frameworks. Of course you need a place to do that object creation and wiring work - but it is not really related to web stuff - it should have it's own place in the program, ideally in a Dependency Injection compartment, not necessarily a container based on the available libraries - but it can also be coded by hand (I might change my minde some day but for now I don't see any reasons to use DI container libraries in a dynamic language like Perl). All the arguments about using Dependency Injection apply also here, but even for someone rejecting DI it should be pretty obvious that reading config files and initializing objects is not much related to web stuff and if you buy the single responsibility principle you should split them into separate libraries. I don't know Django or Rails too deeply - but I've observed this with Catalyst. Now, Catalyst is supposed to be decoupled from the Views or Models and other Plugins, there are many different ones in each category and you can replace them freely in your programs. But Catalyst code-base is still pretty big and then you have all these Catalyst::Models, Catalyst::Views and Catalyst::Plugins that don't really do any meaningful work - they only map one interface into another one. It could be much simpler if Catalyst only cared about the web related processing. (copied from my blog)

by Apreche 14y ago

drivebyacct2 14y ago

I think his point is that this: "You have to go get a third party auth system" is a good thing. That way if the auth implementation needs to change, it can more easily if it's loosely coupled to the application.

anthonyb 14y ago
Django's auth system is not that hard to hack on if you need to - in most cases you just need to write a custom backend and implement a few methods on it. It's certainly comparable to writing your own, or downloading something and integrating it.
- Orf_ 14y ago
  I wrote my own to use SQLAlchemy models you define: http://tomforb.es/using-a-custom-sqlalchemy-users-model-with-django http://tomforb.es/using-a-custom-sqlalchemy-users-model-with... Its really not that bad or hard to do at all.
  - anthonyb 14y ago
    But now you have an auth system that's tightly coupled to SQLAlchemy. How is that different from the regular system, other than you're using SQLAlchemy rather than Django's ORM? I'm also finding it hard to think of a use case where you need to authenticate 100 users at once, so your initial rationale (100 separate updates) doesn't really work. Surely you'd use a different tool to populate your database, but Django's ORM for day to day stuff?
    - zzzeek 14y ago
      Pyramid has an auth system not tied to any ORM or persistence system whatsoever: http://pyramid.readthedocs.org/en/latest/tutorials/wiki/authorization.html http://pyramid.readthedocs.org/en/latest/tutorials/wiki/auth... I'd say that's better than anything hardcoded to a fixed database schema. There's a whole world of development that has no interest in using a mediocre, off the shelf database schema in lieu of one that is designed exactly for the problem at hand.
      - anthonyb 14y ago
        Er, that looks pretty hideous to me. I guess the idea is that Pyramid exposes a lot of the internals so that you can tweak it, but what's going on in that code is completely lost in the noise. From all of the hits that I can see on Stack Overflow, I'm not the only one who finds it hard to understand. Not to mention that it completely punts on adding any sort of persistence for user models or password hashing. I stopped trying to figure out what was going on when I realised that headers = remember(request, login) actually returns the raw headers as a list of strings, and you need to feed them manually back into the response. Compare to Django's login, which is a lot clearer, even though it includes all of the things that the Pyramid version skips over: https://docs.djangoproject.com/en/dev/topics/auth/#django.contrib.auth.login https://docs.djangoproject.com/en/dev/topics/auth/#django.co...
        hysan 14y ago
        Well that's cause the Pyramid Auth API is admitted by the authors to be overly complex. They did a post mortem here and you can read about some of the mistakes they made when designing the API: http://plope.com/pyramid_auth_design_api_postmortem http://plope.com/pyramid_auth_design_api_postmortem The most relevant line to take away from their post mortem is this: "Unfortunately, when designing a framework, you get exactly one shot at creating "the right" API. In this case, we didn't." So even with a decoupled API, if the design doesn't fit your needs or is too cumbersome to use, you will still need to find a third party solution or hack the core code. Both of which, as mentioned by others, are possible in Django.
run4yourlives 14y ago
So basically, you're going to do more work now because it might pay off in the future under certain circumstances? Talk about solving problems you don't have yet. There may be a very good reason for using a third party anything, but to suggest that this is always the "right thing to do" is ludicrous.

megaman821 14y ago

I had a simple Flask app that need an auth so I wrote my own and I wouldn't quite call it simple. There are so many security concerns. What password hashing algorithm to use (PBKDF2, bcrypt, scrypt, etc). Even the password reset mechanism can be an attack vector if one-time login url is generated poorly and an attacker can generate a large volume of password reset requests.

zby 14y ago

You can also have an AUTH library coded against an interface, a protocol - and then use it with may different frameworks. I am convinced that this can be made practical if you choose the interfaces carefully. I have actually coded an auth lib against the PSGI interface (in Perl it is an equivalent of WSGI) plus a few virtual functions to be implemented in subclasses as connection to the storage database: https://github.com/zby/Plack-Middleware-Auth-Form https://github.com/zby/Plack-Middleware-Auth-Form

zby 14y ago

Why web frameworks tend to grow to become such unwieldy beasts? Most of the web frameworks I know tend to do at least two things - the web stuff plus creation and initialization of all other components. This means that the framework is coupled with all of these components and this is the root of all evil in web frameworks. Of course you need a place to do that object creation and wiring work - but it is not really related to web stuff - it should have it's own place in the program, ideally in a Dependency Injection compartment, not necessarily a container based on the available libraries - but it can also be coded by hand (I might change my minde some day but for now I don't see any reasons to use DI container libraries in a dynamic language like Perl). All the arguments about using Dependency Injection apply also here, but even for someone rejecting DI it should be pretty obvious that reading config files and initializing objects is not much related to web stuff and if you buy the single responsibility principle you should split them into separate libraries. I don't know Django or Rails too deeply - but I've observed this with Catalyst. Now, Catalyst is supposed to be decoupled from the Views or Models and other Plugins, there are many different ones in each category and you can replace them freely in your programs. But Catalyst code-base is still pretty big and then you have all these Catalyst::Models, Catalyst::Views and Catalyst::Plugins that don't really do any meaningful work - they only map one interface into another one. It could be much simpler if Catalyst only cared about the web related processing. (copied from my blog)