6 ms·
The Django ORM and DRF autogenerated views are very good for quickly building CRUD APIs. You get a lot of stuff in the box with Django: * a very functional (i
by theptip 9y ago
The Django ORM and DRF autogenerated views are very good for quickly building CRUD APIs.
You get a lot of stuff in the box with Django:
* a very functional (if exceptionally complicated and hard-to-modify) admin UI
* a friendly ORM with good support for autogenerated DB schema migrations (better than SQLAlchemy for simple CRUD, but harder to go off the beaten track when you need to)
And building on that, DRF gives you
* Autogenerated CRUD API endpoints for your DB models
* Autogenerated serializers for your DB models, with field type validation
All of the above exists as plugins for Flask, but the feature set is less well integrated, and you need to figure out which plugin you want to include.
If you're trying to build a super-light microservice then Flask is probably worth looking at, though you can get Django quite light with a bit of work.
If you're trying to build a more complex system with nested API endpoints then DRF makes this harder for you (it's not possible in native DRF, but there's a plugin for it; I'm using this approach so it's not terrible).
And if you don't buy in to Django's ActiveRecord ORM approach (e.g. you want to do DDD and want to use a DataMapper style interface on your DB), then you need SQLAlchemy, and you can't use all the clever ORM mapping tools that Django/DRF brings, and so you may as well use Flask.
- Daishiman 9y ago> a very functional (if exceptionally complicated and hard-to-modify) admin UI The flexibility of the admin UI has improved dramatically in the last few releases. It's still relatively complicated, but it now has way more places to override behavior.
- andybak 9y ago> last few releases By "last few" you mean "since about Django 1.4" in 2012
- andybak 9y ago> exceptionally complicated and hard-to-modify As an exceptionally mediocre programmer who routinely creates extensive admin customisations I dispute this. Seriously. Where does this meme come from? The admin is remarkably easy to customize for the most part. It's biggest flaws are incomplete documentation and a few monolithic methods/templates mostly around changelists.
- andkon 9y agoAt least part of the problem is that it looks so, so weird, and it's really tightly bound to models. This is like the most customized admin i've made and it's still pretty simple, but it sure doesn't feel that easy to reason about when you look at it (it's an admin page that lets you link a specific admin-page input to a model, then display it in a list that you can add to): from django.contrib import admin from django.forms import Textarea from .models import * # Register your models here. class BotTextInline(admin.StackedInline): model = BotReplyContent extra = 1 fieldsets = [ (None, {'fields': ('message_type', 'text', ('template_text', 'example_text',), 'order',)}), ('Actions and inputs', {'classes': ('collapse,'), 'fields': ('action_type', 'input_type',)}) ] # readonly_fields = ['input_type_ptr'] class BotReplyAdmin(admin.ModelAdmin): fieldsets = [ (None, {'fields': ('state', 'intent', 'context', 'description', 'next_state',)}), ] formfield_overrides = { models.CharField: {'widget': Textarea()} } list_display = ('state', 'intent', 'context', 'description',) save_as = True # lets you save the content on screen as a new id inlines = [BotTextInline] admin.site.register(BotReply, BotReplyAdmin) ```
- Daishiman 9y agoThis is a trivial amount of customization. Yes, you have to know what the class fields do. But you just saved yourself days of having to make your own CRUD view from scratch.
- andkon 9y agoTotally trivial. And yet, I still can barely parse what's going on in there.
- Daishiman 9y agoBut proportional to the docs and total customizability and sheer mass of code and functionality that happens. You're getting free authentication for an admin + free UI + a fully customizable list view + customizable create/update view + delete with a useful confirmation dialog + trivial field search + trivial filters of all sorts include date drill-downs. It's a huge amount of things to do by hand.
- pmiller2 9y agoOTOH, using Django + DRF, you will be fighting the framework if you want to do anything besides serialize and deserialize models from your database. We use DRF where I'm at, and I often wish we didn't.
- Daishiman 9y agoIf you're fighting the framework, you're doing it wrong. It is trivial to use serializers for non-ORM stuff. It is trivial to not use serializers at all. It is trivial to plug your own auth and permissions.
- StavrosK 9y agoI'm a heavy Django user, and have used DRF occasionally. I find Django extremely pluggable and extensible, but I needed to write an API with DRF that didn't map cleanly onto the database models, and that was pretty cumbersome. DRF doesn't like it when you do things that don't map to the models, and the documentation is pretty bad. I had to read the source in the end to figure out how to do what I wanted, and I got the sense that I was lucky it was doable. If your database models map to your CRUD endpoints, though, everything is super easy.
- theptip 9y agoI use a lot of custom Serializers (not tied to any Model), and lots of SerializerMethodFields to selectively override generated ModelSerializer fields; this can get you quite far. I agree with your point that the further afield you go, the less you gain from the framework, though.
- StavrosK 9y agoThat's what I ended up doing, if I recall correctly, but the docs on this were pretty much non existent.