I'd argue that for anything other than a very simple microservice that is going to remain static, DRF is the better choice. Its sweet spot is simple to moderately complex domain models, particularly CRUD-based APIs, where you get a _lot_ for free.
It's great to be able to define a DB model, and in a few lines of code have the API endpoint for that DB entity up and running.
When you start getting to complex apps, you may find yourself fighting against the framework somewhat in order to keep your concerns separated, but that's a Hard Problem in general, and so I don't think it's a flaw of the framework itself (though there are a few areas where DRF is opinionated that I think it should not be). If you were using Flask, you'd have more freedom to tweak things when you get to this point, but you'd also have spent 1.5x the dev effort building all of the things that Django/DRF does already.
In short, if you don't know whether you need Django/DRF or Flask, you probably need Django/DRF. Once you have enough experience with Django/DRF to critique that stack's design decisions, you'll be in a position to make good decisions of your own with Flask if Django/DRF doesn't meet your needs.
Another bit of "FUD" I have is that I always consider the database (pgsql say) to be the one thing that won't change, so I create tables in SQL and would keep that even if the service changed from say Python to Go.
With Django, would I be able and would it make sense to keep the SQL schema if I changed languages?
I've not used SQLAlchemy much, but I assume it can be configured to map onto the DB tables that Django has created.
Django has the concept of `apps`, where each app gets its own namespace. So for model `foo` in app `app1`, you get a table `app1_foo`. Inside that table it's just the standard SQL columns that you'd expect. So you might need to override the default table name if your new ORM provides one, but no more than that.
The only other piece that might give you grief is the ContentType machinery; there's a content_type table that has a row for each model class, which lets you do generic foreign key lookups. It might be some work to duplicate that, if you start depending on it. But it's not super-complex; it's just <id, app_label, model> in that table.
Thanks - yes, I'll have to try and see.
In the moment I can only model stuff in terms of SQL, which I like, but becomes tedious typing almost the same query in 50 places...
(My last API was in Go and felt like too much work, even though it worked nicely in the end.)
I'd like to second what the poster above said. My main stack is flask and in my most recent project I decided to use DRF since I was working with a pretty simple data model. It was stunning how much faster it is to go from nothing -> v0 vs building in flask.
I'm in your same situation and I think it really depends on your use case. Are you creating an API that's read-only and only for you or a small internal team? You could pretty easily write that in just about any framework (or even no framework at all).
Once you start adding on features like allowing writes, authentication+authorization, rate limiting, API discovery, client library generation, OAuth support, etc then something like DRF really makes sense.
DRF is pretty darn flexible and it uses Django so you get a lot of functionality for free, including the Django admin if you want a way to explore your data. DRF in no way forces you to use the Django models (or even any models at all).
