2 ms·
I have strong agreement here and would add reasoning about auth flow through nested resolvers is one of the biggest challenges because it adds so much mental ov
by verdverm 11mo ago
I have strong agreement here and would add reasoning about auth flow through nested resolvers is one of the biggest challenges because it adds so much mental overhead. The reason is that a resolver may be called through completely different contexts and you have to account for that
The complexity and time lost to thinking is just not worth it, especially once you ship your GarphQL app to production, you are locking down the request fields anyway (or you're keeping yourself open for more pain)
I even wrote a zero-dependency auth helpers package and that was not enough for me to keep at it
https://github.com/verdverm/graphql-autharoo https://github.com/verdverm/graphql-autharoo
Like OP says, pretty much everything GraphQL can do, you can do better without GraphQL
- cluckindan 11mo agoHave you tried using a decorator for auth? Also, using a proper GraphQL server and not composing it yourself from primitives is usually beneficial.
- verdverm 11mo agoThis was an auth extension or plugin for Apollo, forget what they called it. Apollo shows up in the README and package.json, so I'm not sure why you are assuming I was not using a proper implementation
- hirsin 11mo agoAuthz overhead for graphql is definitely a problem. At GitHub we're adding github app support to the enterprise account APIs, meaning introducing granular permissions for each graphql resource type. Because of the graph aspect, queries don't work til all of the underlying resources have been updated to support github apps. From a juice vs squeeze perspective it's terrible - lots of teams have to do work to update their resources (which given turnover and age they may not even be aware of) before basic queries start working, until you finally hit a critical mass at some high percentage of coverage. Add to all that the prevailing enterprise customer sentiment of "please anything but graphql" and it's a really hard sell - it's practically easier and better to ask teams to rebuild their APIs in REST than update the graphql.
- deleted 11mo ago[deleted]
- andrewingram 11mo agoI mean, the use of GraphQL for third party APIs has always been questionable wisdom. I’m about a big a GraphQL fan as it gets, but I’ve always come down on the side of being very skeptical that it’s suitable for anything beyond its primary use case — serving the needs of 1st-party UI clients.
- hirsin 11mo agoStrongly agreed.
- verdverm 11mo agoGitHub search is among the worst out there, is this why?