It's simple, django-filter

[engAmirEng]

Your competitor (graphene) supports relay based on django-filter, in the other hand you implement your own filter that has bugs and is not as good, existing projects use django-filter and if you support it then you are the obvious choices since you have a decent subscription support, so please do it

Upvote & Fund

• We're using Polar.sh so you can upvote and help fund this issue.
• We receive the funding once the issue is completed & confirmed by you.
• Thank you in advance for helping prioritize & fund our backlog.

[bellini666]

Hi @engAmirEng ,

I do agree that having support for django-filter would be nice :)

Currently I'm lacking time for some improvements and when I do have I'm trying to solve other issues, but I can totally help and guide anyone wanting to tackle this issue. If you or anyone wants to try, ping me either here or on discord

[callmeUmer]

@bellini666 I can dedicate my time on this issue, I would need a little bit of your guidance

[bellini666]

@callmeUmer awesome! :)

And sure, let me know what you need. As I said, we can continue the discussion either here or you can ping me on discord: https://strawberry.rocks/discord . My username there is bellini

[arthanson]

Big +1 for Django-filter support. I noticed you used to have support (v0.1.8 or so) and then it was dropped when the switch to dataclasses was done. At https://github.com/netbox-community/netbox we were looking to switch from graphene to strawberry but the lack of django-filter support is a big problem, and django-filter is pretty much a standard now for a lot of Django projects.

[cpontvieux-systra]

-1 for Django-filter. Most of bugs in graphene comes from the try to fit django-filter project into something not meant to be. I prefer the simpler approach done for now in strawberry-django. django-filter has not been created to integrate in graphql project and try to doing it is not a good idea. By the way, the source code of django-filter is not that big, it’s easy to just use/adapt the right part than try to force-fit this project in a graphql context.

Sometimes, reuse is not the answer (even if most of the time it is).

P.S. I love django-filter by the way, just not for this use case.

[patrick91]

@cpontvieux-systra I think I agree with you 😊 for someone like me who hasn't used django filters, would you be able to provide some of the reason why you don't think it is a good idea to integrate it here?

[thclark]

Just chiming in with some feedback from my dev team- they're loving strawberry filters (after porting an app over from graphene+relay+django_filters), finding it simpler to implement.

Consistency between relay and non-relay implementations is a benefit too, whereas with graphene you had completely different implementation either way.

The only comment was that it'd have been better if the filter names had been consistent with django_filter (at least where possible, eg in vs in_list) but I imagine there were informed choices underlying the change?

Overall, I think I'd be inclined to suggest that you have something that's working really well and that an integration with django_filter might make things very brittle (and perhaps very difficult in terms of future work in the query optimiser). Perhaps there's some name changing that could be done to ease cognitive burden when transitioning from DRF+filters -> strawberry, or graphene+filters -> strawbery though?

Has anyone got any use cases that can be done in django_filter but can't be done with strawberry?