4 ms·

This is just my personal experience, but once you try to do certain things with Django, you start to butt heads with it. Django relies far too much on conventio

This is just my personal experience, but once you try to do certain things with Django, you start to butt heads with it. Django relies far too much on convention, and it shoehorns you into their tooling patterns. I think the most exciting and flexible way to do things these days is with a collection of microservices. You can do feature work independently, test small isolable units of functionality, and achieve scale.That said, we could use cross-cutting libraries to make microservice implementation easier...

wahnfrieden 12y ago
Have concrete examples where Django gets in the way? Re: microservices, I think it's much healthier to frame that debate as a matter of tradeoffs rather than one approach being universally better suited than the other.
- oq64diyt 12y ago
  > Have concrete examples where Django gets in the way? Add support for multiple-column primary keys https://code.djangoproject.com/ticket/373 https://code.djangoproject.com/ticket/373 Opened 9 years ago NULL fields and Unique keys https://code.djangoproject.com/ticket/4136 https://code.djangoproject.com/ticket/4136 Opened 7 years ago
  - nkuttler 12y ago
    So you're saying things nobody cared enough about to get them implemented in 7+ years? You'll find bugs old like this in any open source project.
gtaylor 12y ago
We've been pretty happy with it at Pathwright. 1.7 was a great release. The conventions aren't too restrictive, and it has been incredibly easy to get contractors plugged in and productive in minimal time. We follow many best practices, so our codebase is going to be "familiar" (to some extent) to anyone with some experience. We love Django for the productivity level our team achieves with it. The ecosystem is great, too. django-rest-framework in particular makes us oh-so-happy. Not to knock flask/Pyramid/everything else. Pick what your team can be most productive wit. I just think there are less reasons than ever to get too caught up in choice of framework. There are so many great options now.
- ryan_sb 12y ago
  > Pick what your team can be most productive with Absolutely. If you already know one and like it, go forth and hack. If you're not sure, or don't like the one you have, there are tons of great options. Not just Flask/Django/Pyramid either. Tornado, Bottle, CherryPy, Falcon, and more all have dedicated users (some more than others).
edwinnathaniel 12y ago
Ever since the beginning of the rise of microservice "architecture" we all know that a complete web-framework like Rails/Django does not fit the toolbox so I would suggest not to discuss the excess baggage/shortcoming of software X that is 90% designed to do Y to be applied to a different problem domain. Developers tend to get excited building microservices because let's be honest, most of us aren't Ops that have to watch those services 24/7. During the development of Microservices, everything looks rosy, as things evolved, if the organization does not have the skill-sets and the discipline to maintain these microservices, things fall down pretty quickly. Take logging as an example, I'm betting that many microservices implementation would find it a wee bit challenging to trace a user transaction end-to-end.

wahnfrieden 12y ago

Have concrete examples where Django gets in the way? Re: microservices, I think it's much healthier to frame that debate as a matter of tradeoffs rather than one approach being universally better suited than the other.

oq64diyt 12y ago
> Have concrete examples where Django gets in the way? Add support for multiple-column primary keys https://code.djangoproject.com/ticket/373 https://code.djangoproject.com/ticket/373 Opened 9 years ago NULL fields and Unique keys https://code.djangoproject.com/ticket/4136 https://code.djangoproject.com/ticket/4136 Opened 7 years ago
- nkuttler 12y ago
  So you're saying things nobody cared enough about to get them implemented in 7+ years? You'll find bugs old like this in any open source project.

gtaylor 12y ago

We've been pretty happy with it at Pathwright. 1.7 was a great release. The conventions aren't too restrictive, and it has been incredibly easy to get contractors plugged in and productive in minimal time. We follow many best practices, so our codebase is going to be "familiar" (to some extent) to anyone with some experience. We love Django for the productivity level our team achieves with it. The ecosystem is great, too. django-rest-framework in particular makes us oh-so-happy. Not to knock flask/Pyramid/everything else. Pick what your team can be most productive wit. I just think there are less reasons than ever to get too caught up in choice of framework. There are so many great options now.

ryan_sb 12y ago
> Pick what your team can be most productive with Absolutely. If you already know one and like it, go forth and hack. If you're not sure, or don't like the one you have, there are tons of great options. Not just Flask/Django/Pyramid either. Tornado, Bottle, CherryPy, Falcon, and more all have dedicated users (some more than others).

edwinnathaniel 12y ago

Ever since the beginning of the rise of microservice "architecture" we all know that a complete web-framework like Rails/Django does not fit the toolbox so I would suggest not to discuss the excess baggage/shortcoming of software X that is 90% designed to do Y to be applied to a different problem domain. Developers tend to get excited building microservices because let's be honest, most of us aren't Ops that have to watch those services 24/7. During the development of Microservices, everything looks rosy, as things evolved, if the organization does not have the skill-sets and the discipline to maintain these microservices, things fall down pretty quickly. Take logging as an example, I'm betting that many microservices implementation would find it a wee bit challenging to trace a user transaction end-to-end.