6 ms·
I don’t align with your view, let me share my view. The GitHub web hooks (which is basically REST) post a deeply nested json full of nodes (that you “might nee
by joshribakoff 5y ago
I don’t align with your view, let me share my view.
The GitHub web hooks (which is basically REST) post a deeply nested json full of nodes (that you “might need”) which I don’t need, and lacking info I do need (ended up having to do another round trip to GQL after receiving the bloated web hook payload)
I have seen suboptimal APIs on both technologies.
If you don’t have control over the API, it doesn’t matter if it uses SQL, so following your logic the issue seems to be that you cannot change the API, not the tech it uses.
- tyingq 5y agoWe're probably closer on views than you think. REST apis can return unneeded nesting too...I get that. The difference is the culture/background/ecosystem around GraphQL, which makes it happen more often. It's the easy path there.
- nivertech 5y agoIt's recommended to use nesting in GraphQL objects (both inputs and responses) for backward- and future compatibility. But your problem is mostly because the API is not under your control. In GraphQL backends it's OK to add special queries adapted for specific UI/UX (I think it's the whole idea behind the BFF - Backend-For-Frontend pattern). I.e. you can choose between Design-first (data-centric) or Client-first (optimized for rendering on the Client/Front-end) GraphQL schema methodologies. In the Client-first GraphQL schema you can have queries returning flattened data. A non-standard approach is to run transformations, i.e. you specify directives how to transform the GraphQL operation responses. This can be for flattening, aggregations, calculating statistics, or joining results of the different queries. https://www.graphql-mesh.com/docs/getting-started/mesh-transforms https://www.graphql-mesh.com/docs/getting-started/mesh-trans...