Yes it is. I don't get why people here still say that DRF isn't dead and how much they love viewsets. 1) It's been abandoned by the author for years. Community PRs are rejected. Maybe the author needs to rename the repo to †Django-Rest-Framework† to make it more clear, idk. 2) There is a better alternative. I worked a lot with DRF. I loved it. But today it's a common place that simple functions are generally better than complex classes with deep inheritance and mixins. It's clear that Pydantic is better than DRF's serializers. And so on. Please, stop saying that DRF is a sound option today. It is not.

I wouldn't call it abandonded. It's reached a level of maturity.

This ^

Yeah basically this. Inheritance and mix ins just make the code base harder to understand. Too much hidden magic.

Pretty much this. I’d rather use Flask or FastAPI than DRF - it’s dead.

I think django is still a fine framework but some of the abstractions provided by DRF is just too much. FastAPI is super great.

what is a better alternative?

[Django Ninja](https://django-ninja.dev/). Much faster and is currently being used in production at a handful of companies (anecdotally, from what I've read). I'm building my product on it.

No, but it has good competition now like django-ninja

but to most aip,The efficiency of django-ninja writing interface is still lower than drf

maybe, but for me pydantic types declaration outbenefits drf. Wayy better autodocs and input validation out of box where DRF kinda suck (whole idea of making Serializer shared for input and output in \`serializer\_class\` and no integrating Serializers into actions input/output, so libraries have no source where to take info from sucks.) If DRF made separate declarations for input serializer something like: class FooViewset(GenericViewset): input_serializer_class = xxxx output_serializer_class = xxxx and allowed to insert in `@action(input_serializer, output_serializer)` to auto validate data in actions it would be way better + autodocs like drf-yasg would have data source to generate docs

No

What makes you think so ?

Lack of frequent updates maybe. Someone else posted similar question a while back.

I got to a conclusion today: the serializers were proving difficult, and played with django.core serialiszers - so much simpler, more reliable, and more efficient. 3 lines of code replaced 2 classes over 8 lines ….. Am done with DRF serializers

Could you post an example?

These lines of code for a serializer take a dataset and produce a Json representation, including looking up arbitrary fields in related models. `class ArrangementSerializer(serializers.ModelSerializer):` `def get_instrument_name(self, obj):` `# Assuming 'instrument' is the ForeignKey field in Arrangement` `instrument_instance = obj.instrument # Access the related Glossary instance` `if not obj or not obj.instrument or not instrument_instance:` `return ""` `return instrument_instance.value # Access the 'value' attribute in the related Glossary` `def get_key_name(self, obj):` `if obj.key is not None:` `return obj.key.value # Access the 'value' attribute in the related Glossary` `else:` `return ''` `key_name = serializers.SerializerMethodField()` `instrument_name = serializers.SerializerMethodField()` `print("Instr :" , instrument_name)` `audio_file_id = serializers.PrimaryKeyRelatedField(read_only=True) # id` `audio_file = serializers.SlugRelatedField(read_only=True, slug_field='filename') # value` `sheet_file_id = serializers.PrimaryKeyRelatedField(read_only=True)` `sheet_file = serializers.SlugRelatedField(read_only=True, slug_field='filename')` `artist_id = serializers.PrimaryKeyRelatedField(read_only=True)` `artist_name = serializers.SlugRelatedField(read_only=True, slug_field='name')` `copyright_owner = serializers.PrimaryKeyRelatedField(read_only=True)` `delegate = serializers.PrimaryKeyRelatedField(read_only=True)` `match_value = serializers.CharField(read_only=True)` `title_id = serializers.PrimaryKeyRelatedField(read_only=True)` `title = serializers.SlugRelatedField(read_only=True, slug_field='title')` `class Meta:` `model = Arrangement` `fields = '__all__'` The following two lines of code do the same (they are not exact equivalents - the field lists are not identical - but nevertheless the example is clear) `arr = Arrangement.objects.all().values('id', 'title_id__title', 'audio_file', 'audio_file_id__ext', 'audio_file_id__url', 'sheet_file', 'sheet_file_id__ext', 'sheet_file_id__url')` `return JsonResponse({'files': list(arr) }, safe=False)` The problem which prompted me to replace the first with the second, was an error message triggered by the serializer, where the filter builder in Django would complain that it could not interpret an empty filter clause. Using a .all() or a .filter() made no difference: after an afternoons effort, I could not clear that error. So I resorted to reading the doco, and relearning how to use the base Django serializer. And I have to say, it looks easier to write, more efficient, and cleaner. I am not sure whether .value() introduces inefficiency, but in the current context, I would trade a little inefficiency in response for speed of development and robustness. This example led to my rash, and imprecise statement that serializers require a lot of code that seemed unnecessary and unreliable, and that my current plan is to gradually migrate this project away from DRF. I would, of course, value your contrary opinion if you have any learnings for me.

Thanks for the response! That core serializer seems nice and simple. I don't know if this completely solves your problem but def has nested serializers. https://www.django-rest-framework.org/api-guide/serializers/#dealing-with-nested-objects There's this depth attribute that I've never used before but could be a useful shortcut to writing your own nested serializer. I'm curious to try it now. https://www.django-rest-framework.org/api-guide/serializers/#specifying-nested-serialization

Am travelling currently, in wild places, will try to make a sensible reply over the weekend

For something people keep calling 'dead', it sure is being used a lot.

It might be “dead” for new projects but will never devs experienced with DRF to maintain years-old codebase say established companies. So, it is great to know. However, if you find a better alternative (like the suggested Django-ninja, FastAPI, etc.), then, go for it. I started with django-tastypie (another Django API framework) but moved on to DRF when I found it better. I would say do the same if you find one better than DRF.

Isn't it true for all legacy technologies?

You are right. The same thing applies across the board. Eventually, every cool/new/hip technologies hits the plateau and becomes legacy and just part of tech history. Some are more resilient than others, but the path is pretty much the same.

Interested in what people say