Anonymizing GraphQL Resolvers with Decorators
petecorey.com
Anonymizing GraphQL Resolvers with Decorators
1–3 of 3 posts
Re: Anonymizing GraphQL Resolvers with Decorators
#2I’m not a fan.
This approach adds a conditional layer on top of the whole application, it does so to support “showing” (aka sales) with no benefit to the user and... it actually exposes user data to third parties with all risks involved.
I’d prefer (as developer and as an end user) mock demo users.
Re: Anonymizing GraphQL Resolvers with Decorators
#3I’m not a fan. This approach adds a conditional layer on top of the whole application, it does so to support “showing” (aka sales) with no benefit to the user and... it actually exposes user data to third parties with all risks involved. I’d prefer (as developer and as an end user) mock demo users.
Anonymization vs “just use a demo database” (which I tend to agree with) aside, there’s significant value, at least, in illustrating the concept of Decorators as a pattern for transforming data for presentation, and how that can be hoisted into a transformation of the resolvers’ results to apply them automatically. I’ve seen way too many codebases dumbly copy-and-pasting identical logic like this between each and every resolver, with all of the attendant “whoops, forgot a place” bugs.
There’s seemingly a real lack of knowledge of either the existence of better abstractions or the knowledge of how they can be applied in GraphQL implementations in a lot of shops, currently.