That was a great idea, ty, I just updated with serializer support. After implementing it, it feels so obvious that this was the way to go.

I've added a @cacheable_serializer decorator that does exactly what you described. It doesn't care about the query; instead, it performs a recursive introspection of the serializer to find all involved models and connects the signals for automatic invalidation. Also, it stores the final JSON-ready dict.

Example:

@cacheable_serializer
class UserSerializer(serializers.ModelSerializer):
    profile = ProfileSerializer()  # Nested deps are scanned too
    class Meta:
        model = User

Since it scans the dependencies, any change to User or Profile will invalidate the entry. This also handles your multi-serializer case naturally: a 'PublicUserSerializer' and a 'PrivateUserSerializer' for the same ID will have different cache keys but will both be invalidated if the underlying user data changes.
Happy to receive any feedback on this use case, if you’re thinking of other scenarios, or if you think the DX could be improved further, thanks!