I went with Django Rest Framework when I used it for a project because it provided things I would otherwise spend says implementing out of the box. The one thing I definitely did implement for myself was filtering, the built-in stuff was kind of mediocre for our needs, outside of that I want to say we left pagination and everything else as-is. It was a bit of a nightmare to look up documentation on though I will admit, if you don't know the Google Buzzword Soup you got to look up. Previously to that I was using CherryPy and building my entire kitchen sink myself, so it had nice moments and bad moments, but it definitely saved me on time and effort.

You typically do Django + REST because you are already comfortable with Django or because you were already using it, although I could argue, you could consider making your API project stand alone and using CherryPy or even FastAPI for a much nicer experience. The downside there being you wouldn't be using Django's ORM. I really do wish Django's ORM would be spun off into a stand alone project that Django then imports, so anyone else can use it in other non-django specific projects.

I remember watching a beautiful talk from some pycon whose details I can’t remember about using django as if it was a micro-framework.

It basically boils down to rejecting the folder structure that django-admin sets up for you, importing stuff yourself and doing some basic initialisation/configuration.

Once you do that, django kinda somehow behaves like a micro-framework, with the significant difference that you can import and use the advanced features if you want/need to.

Here is an example of a single file Django project I started around eight years ago that does what you mention:

https://github.com/planetfederal/registry/blob/149a2b958dd05...

I guess I prefer to keep it light and use a true microframework like flask for this use case. I find I can similarly import Flask extensions without bringing in a full heavy framework

PonyORM is sort of like Django's

Proper Django Rest Framework should basically have zero view code. Treat Serializers as forms, point at them in the appropriate generic view (or viewset) subclass, and you are done.

If you are writing view code in DRF, you are probably doing it wrong.

I don’t think this is fair - the DRF views are a great starting point for a project but I don’t think I’ve ever worked on one where they’re totally sufficient without at least some modification in places if you don’t want to make use of signals (which are very difficult to debug!).

Even things as simple as adding logging to calls on certain end points will require you do provide your own view method (which might then call the mixin’s provided method).

I don't find it has a lot of overhead if you keep it simple. No need to use class based views for REST services, just add function-based views with the @api_view decorator.

You can then within minutes return JSON coming from your data model by also adding an additional decorator to make it render JSON output.

If returning data directly from managed ORM objects, you will need to serialize it, but you can easily build an API without doing that and just return a dict.

It all depends how it is written. While Django and REST is quite strongly opinionated, you can still make it difficult to maintain if you want to. That being said, Django REST allows you to move fast. It's very very easy to knock out a REST API and data models plus some basic admin panel. Once your API matures - you can then reimplement it in Go or other platform.

It really shines if you are doing simple CRUD APIs where you can lean on autogenerated routes, views, and serializers. Since you can get full CRUD for a model in something like 10 lines of code.

When you need to wire up custom serializers per model (eg specifying subsets of fields or making some read-only) and wire up non-CRUD actions then I think you can fall down a slippery slope where you write as much (or more) code than if you just used say marshmallow and flask to manually write your API.

Also you get the Django model admin for free, so for internal services you have a nice CRUD admin for operators.

I think it’s a great tool for accelerating your first 100-200kloc of API code. Beyond that it can start to creak at the seams depending on your usecase. (I’d make the same assessment about Django itself FWIW).

It's a really easy framework that just takes a few days to get proficient in. It is very well documented and because it comes with so much "overhead" you don't have to get your own team to make a set of different mistakes building the features as needed.

If I had a dollar for every time I heard this I would be having lunch with Jeff Bezos right now.

every python developer has accidentally made django at least once.

you start with "i will do in flask because it's easier". then you need to add authorization/authentication. and then templating, ORM, maybe some RESTful flask library to make endpoints a bit easier... and now you have django, but in a different way.

This 1000x. It's such a slippery slope that you'd think by now most people would be aware but no, there's always the "who needs an ORM" guy :)

I just make normal money and I don't want to have lunch with Jeff Bezos. Maybe in this scenario you lose money each time you hear it and you're so in debt that Jeff Bezos has basically purchased you :P.

Gross, why would you want this? Improve your standards matey. What a sad thing to aspire to.

Why do a REST-like service?

It makes sense as backend for a native iOS/Android app, and if you already have that REST endpoint then it can make sense to re-use it for the web-version of your app.

But if you're not doing an iOS/Android app (most websites?), then I generally agree it's a lot more work compared to form-based / server-side-templates (though sometimes can give a _slightly_ better user experience, _if_ done correctly.)

HTMX seems to be growing as a "REST endpoint" alternative, but again not as useful if you're also doing a native iOS/Android app.

In this day and age, mobile apps are _almost_ a must so REST is everywhere.

A well-implemented REST app is pretty nice, business logic divorced from all UI and API lends itself nicely as a comfortable and maintainable programming environment. More often than not, being RESTful from the get-go tends to have positive returns down the line.

> In this day and age, mobile apps are _almost_ a must so REST is everywhere.

This really isn't true. Mobile apps are far more expensive to develop (everything is doubled, you're dealing with periodic forced updates outside of your development schedule, etc.) and there are a ton of apps which don't need anything you can't do in a browser.

One of the earliest things to do on a project is agreeing on what level of complexity makes sense for you. If your project doesn't have a known hard requirement for mobile apps and correspondingly large team sizes, a classic Django app is likely to let you iterate an order of magnitude faster at lower cost overall.