3 ms·

I like Django a lot and use it for my projects and with clients. > One of the best thing about Django is, it's never gets involved with bubble type technologie

I like Django a lot and use it for my projects and with clients. > One of the best thing about Django is, it's never gets involved with bubble type technologies until proven reliable and useful. Django has also chosen not to get involved in tech that *has* been proven reliable and useful. For example moving to incorporate a formal API library like DRF years ago. It also has not indicated plans to adopt a type-based API library like FastAPI or Ninja. Often this idea of supporting REST API building as a battery of Django is used as a cudgel against modern front-end frameworks. The comments are generally aimed at React, but broadly anything in Javascript that requires an API. However, doing so has also been expense of making Django a first choice for microservices and ignores the important role of serving mobile app clients. Django has also been slow to discard technology that is no longer reliable or useful. For example, jQuery is still endemic in the ecosystem. I'm all for stability--I've invested a lot of time in Django and it is very productive. However, the biggest threat to this framework is the effusive self-praise for this attribute. People would do well to remember that Django displaced Drupal because Django was iterating rapidly even though it made upgrades very challenging at times. FastAPI and now SQLModel are showing how valuable adoption and use of Python's type system can be. There is no reason why a new Python-based framework (apart from Flask) could not unseat Django as the framework of choice. It wouldn't even endanger Django. People still build using Drupal today.

soperj 5y ago
why would you want a full framework with a admin back end for a microservice?
- bb88 5y ago
  In fairness, you can disable the admin service if you want, then it just makes Django a big fat bloaty library. But more to the point, I feel like DRF is kind and of a weird solution anyway, like the request object is different from Django, it doesn't support schema generation without some third party libraries... Frankly, FastAPI with an orm sounds like the ultimate python microservice framework, anyway. Pgcli works as an admin interface in a pinch.
  - holler 5y ago
    Agree. What advantage does FastAPI have over Starlette on it's own? I've written my latest api w/Starlette and found it to be excellent.
    - esclerofilo 5y ago
      Very comfortable pydantic integration. This gives you Swagger docs and type checking for free. I've never actually used starlette directly, but it doesn't sound very ergonomic
- Nextgrid 5y ago
  The batteries included with it. A consistent DB interface, ORM and migration system (independent of the underlying DB), same for cache (similarly you can swap Redis for Memcache and your code doesn't have to change), same for e-mails (swapping e-mail providers is a matter of writing a new backend, application code doesn't change), etc. Sure, you could do all this with Flask and SQLAlchemy, but Flask and these minimalist frameworks always feel like they lack structure and good conventions which means every project does its own thing. In Flask & SQLAlchemy I still don't have a good way of organizing my application and model classes considering they have to inherit from an instantiated DB connection object. I'm sure there's a way and I haven't researched enough, but why bother when Django solves this problem with "one true way" that everyone conforms to? Also keep in mind that despite Django having many features, only those that you actually use will be invoked; you can slim it down further by removing some middleware (hooks that run upon every HTTP request lifecycle) but even in its default configuration it's pretty light - for example the admin is not loaded nor evaluated unless you actually assign it to a URL route and a request hits it. Same for the HTML templating support - unless you actually render a template from a view it's as if it didn't exist - you only waste some disk space but there's no runtime performance hit.

soperj 5y ago

why would you want a full framework with a admin back end for a microservice?

bb88 5y ago
In fairness, you can disable the admin service if you want, then it just makes Django a big fat bloaty library. But more to the point, I feel like DRF is kind and of a weird solution anyway, like the request object is different from Django, it doesn't support schema generation without some third party libraries... Frankly, FastAPI with an orm sounds like the ultimate python microservice framework, anyway. Pgcli works as an admin interface in a pinch.
- holler 5y ago
  Agree. What advantage does FastAPI have over Starlette on it's own? I've written my latest api w/Starlette and found it to be excellent.
  - esclerofilo 5y ago
    Very comfortable pydantic integration. This gives you Swagger docs and type checking for free. I've never actually used starlette directly, but it doesn't sound very ergonomic
Nextgrid 5y ago
The batteries included with it. A consistent DB interface, ORM and migration system (independent of the underlying DB), same for cache (similarly you can swap Redis for Memcache and your code doesn't have to change), same for e-mails (swapping e-mail providers is a matter of writing a new backend, application code doesn't change), etc. Sure, you could do all this with Flask and SQLAlchemy, but Flask and these minimalist frameworks always feel like they lack structure and good conventions which means every project does its own thing. In Flask & SQLAlchemy I still don't have a good way of organizing my application and model classes considering they have to inherit from an instantiated DB connection object. I'm sure there's a way and I haven't researched enough, but why bother when Django solves this problem with "one true way" that everyone conforms to? Also keep in mind that despite Django having many features, only those that you actually use will be invoked; you can slim it down further by removing some middleware (hooks that run upon every HTTP request lifecycle) but even in its default configuration it's pretty light - for example the admin is not loaded nor evaluated unless you actually assign it to a URL route and a request hits it. Same for the HTML templating support - unless you actually render a template from a view it's as if it didn't exist - you only waste some disk space but there's no runtime performance hit.