3 ms·
GraphQL basically only really works with monoliths that share the same access-pattern (either everyone logged in, or everyone logged out), it's otherwise a pain
by BillyTheKing 2y ago
GraphQL basically only really works with monoliths that share the same access-pattern (either everyone logged in, or everyone logged out), it's otherwise a pain to merge multiple different graphql-schemas into a single one (or at least I'm not aware of an elegant way to achieve that).. The worst of two worlds is a micro-services back-end with a graphql Api interface, it makes testing individual services and the Api as a whole quite annoying.
I do really like the Api definition part of it though - but I found something like typespec now to be the perfect middle-ground, it allows out you describe your apis similar to a graphql Api without enforcing the graphql engine on you though.
- manquer 2y agoHasura does role based access control pretty well. Apollo federation and implementation of supergraph and nested graphs is pretty robust We use both in production at reasonable scale and complexity 10+ roles few hundred object models, 100s of request/sec
- tisdadd 2y agoI remember having to solve the merge in the past and we ended up using a merging tool pretty easily to do so. Believe it was this one? https://the-guild.dev/graphql/tools/docs/schema-merging https://the-guild.dev/graphql/tools/docs/schema-merging We were basically just enhancing an external graph with some of our own stuff added on though so fairly straightforward.
- kabes 2y agoTrue, but rest calls over multiple micro services is even worse