RFC: Library maintenance

[dbrgn]

I'm currently lacking the time to properly maintain this library. There are currently two open pull requests that I would like to review, but for which I can't really find time and motivation to do so.

This library has started out as a very simple mixin but has grown in scope and is currently doing more than I personally need. More features also mean more complexity in maintenance and PR review.

There is currently another crate doing similar things, https://github.com/rsinger86/drf-flex-fields. The scope seems similar but drf-flex-fields seems to be more powerful regarding the filters. I'm not totally sure how the feature level compares.

Having two libraries doing simliar things is a waste of time, so I could imagine three options:

• Adding more maintainers to this crate
• Removing all advanced filtering to simplify the crate ("back to the roots") and send people to drf-flex-fields for the advanced stuff
• Deprecating the crate in favor of drf-flex-fields

I'm not sure whether drf-flex-fields would cover all use cases. What do users of drf-dynamic-fields think?

CCing all people somehow involved:

@jtrain
@cb109
@ryanrich
@rsinger86

[cb109]

Hey thanks for your quick response to my PR. Personally, I am satisfied with what this package does exept for the lack of an option to specify the omit and fields directly on a Serializer object, which is what the PR adds. However, this is not mission critical and I have a workaround I can use.

I chose this package being aware of the more powerful and complex alternatives, because it is simple and does what I want with a clean and explicit interface. Everything else pretty much looks like GraphQL to me and is overkill for my needs.

Simple packages can be appealing compared to others, so if I were in your situation, honestly I might reject adding additional functionality to the package and choose option 2. No worries about my PR, it's fine.

Update: It also seems drf-flex-fields supports my above requirement so I could migrate over https://github.com/rsinger86/drf-flex-fields#from-serializer-options

[jtrain]

@dbrgn I myself wanted some omit and fields functionality (some fields are expensive to compute), and so that functionality is already part of our library.

Although @cb109 , what you wanted was omit and fields specified directly on the Serializer, at the time you instantiate it. I had a request for this here: #13
I am sympathetic to that need.

I also wrote my own mixin that does this, standardising it somewhere would be nice.

However, since I wrote that feature request, I've found that doing this filtering on a nested ModelSerializer is very expensive. Specifically DRF's get_fields function on a ModelSerializer takes a long time to compute. Instead I just wrote another plain Serializer that is used in the nested context that only has the fields I want. There is some additional boilerplate with this solution, but all the logic isn't in the serializer anyway, so there isn't any duplication.

So, based on this performance finding, I'm not really excited about supporting nested serializer fields and omit in this library anymore.

[dbrgn]

I could imagine keeping the current feature level, with a policy of not adding any new features but accepting bugfixes and improvements to the current state to keep things simple.

Would anyone be interested in helping with maintenance?

[jtrain]

@dbrgn I would agree with that. And I'm still happy to help out maintaining, we have no plans to switch out this library, it does its job very well.

This library remains about filtering fields based on individual requests, and doesn't expand to include filtering fields when creating the instance (useful in nested serializers).

For those reading this, and wondering why we wouldn't want to support nested serializers better, my answer will be that I've found that to be very slow, and a plain serializer.Serializer to be much faster in nested situations.

[dbrgn]

@jtrain great, thanks for offering help! I added you as collaborator.