Exposing bare GraphQL the right way can be challenging, totally agree with author on that. Using it on a small project also can be an overkill.
But at the same time it doesn’t have to be that bad. I don’t have this array of issues because I do:
- query whitelisting for performance and security,
- data loading to avoid n+1, authentication with whatever works(session cookies, tokens),
- permission check based on the auth context in a resolver.
It works decently for us, allowing to stay away from getting into ESB. Yet have some shared domain, type safety, and easy integration of legacy and new systems/services.
I would say a bigger issue for us was to keep it all nicely organized / designed in terms of types and api contracts. But that’s manageable.
But at the same time it doesn’t have to be that bad. I don’t have this array of issues because I do: - query whitelisting for performance and security, - data loading to avoid n+1, authentication with whatever works(session cookies, tokens), - permission check based on the auth context in a resolver.
It works decently for us, allowing to stay away from getting into ESB. Yet have some shared domain, type safety, and easy integration of legacy and new systems/services.
I would say a bigger issue for us was to keep it all nicely organized / designed in terms of types and api contracts. But that’s manageable.