serializer.update vs viewset.perform_update, etc

[Chris Routh (Routhinator)]

Hi folks,

I'm looking to apply best practices/implementations to a codebase that I've developed in a silo over the last couple of years. Looking back at my code I've been a bit all over the place and I'm struggling to find some answers to a question that's popping up.

In viewsets, we have the `.perform_create` and `.perform_update` methods we can override for more advanced parsing/saving. In serializers, we have `.create` and `.update`

The question I have is, which of these should we be using? What are the pros/cons of using one or the other? 

The DRF docs are rather sparse on this specific point.

Cheers,

Chris

[Abhishek Chauhan]

Hi there, 

I too have worked is silo but I believe that whatever logic you want to apply it should be done in the viewset level, by overriding the methods. I think that serializers are more close to the DB and whatever logic one has to apply it can be done in the views. Once i had to pop out a field and I did that in one of the serializers  method . 

Not sure 🤔 if my explanation helped you but probably you got a gist of my viewpoint on your question .

--
You received this message because you are subscribed to the Google Groups "Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-rest-fram...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-rest-framework/6f5196f9-9bf1-46cb-af98-4ca390d1743an%40googlegroups.com.

--

Abhishek Chauhan

✆ : 9560 432 275

 @abhiazh

[Chris Routh (Routhinator)]

This is definitely a take that's different than mine. That's great, I am looking for opinions.

Personally, I think of model.save and being "close to the DB" - this is where things that _must_ happen for data integrity go. If it's got to happen the same way regardless of how/when a model is saved, it goes here.

Viewsets define an API - and if an endpoint has a specific requirement do something different with the data, it makes sense to put things here.

Serializers are a definition of what is accepted, how it is validated and how the data is represented... I think of them as being closer to the client and a standard way for any endpoint dealing with a specific model to define that interaction.

That said - the difference between when to use the serializer vs the viewset methods for specific things seems sort of fuzzy to me. I feel like maybe we should be leveraging the serializer moreso than the viewset, so that viewsets only pull the pieces of an api endpoint together (serializer, permissions, actions, etc) and the serializer deals with the business... but I'm not sure. For example I needed to use the viewset.create method on one to deal with data post validation.. but maybe I could have also done that in the serializer...

[Anye Shafer]

This, exactly.  Global requirements (either validation or save activities) should be handled by the serializer, so that as you add new endpoints you can ensure those requirements are enforced consistently.  Otherwise, you run the risk that someone who doesn't fully understand these global requirements might circumvent them.  They could still do that if they define a new serializer, but by using 'base' serializers for these global requirements and deriving them in order to change the response format for different endpoints, you can build practices that people follow that help people "fall into" these best practices.

Cheers,

Anye

On Wednesday, October 5, 2022 at 12:26:31 PM UTC-4 ch...@routh.io wrote:

*snip*

Personally, I think of model.save and being "close to the DB" - this is where things that _must_ happen for data integrity go. If it's got to happen the same way regardless of how/when a model is saved, it goes here.

Viewsets define an API - and if an endpoint has a specific requirement do something different with the data, it makes sense to put things here.

*snip*