3 ms·
> such as dealing with n+1 queries This is a rare issue with REST but extremely common with GraphQL. > Additionally, tools like Pothos enable easy ways to get
by pier25 4y ago
> such as dealing with n+1 queries
This is a rare issue with REST but extremely common with GraphQL.
> Additionally, tools like Pothos enable easy ways to get around these
With GraphQL there's always a need of more dependencies. Apollo, Hasura, Pothos, etc. In contrast, you can get REST going with nothing but vanilla stuff.
- satvikpendem 4y ago> With GraphQL there's always a need of more dependencies. Apollo, Hasura, Pothos, etc. In contrast, you can get REST going with nothing but vanilla stuff. Well, one is a web standard and the other is not. Of course more dependencies are needed, it's no different than using a custom format library to parse said custom format. Additionally, you don't need Pothos or any other tool at all, if you want you can take the raw GraphQL query and send back whatever response you want from your server. The dependencies just make life easier.
- pier25 4y ago> if you want you can take the raw GraphQL query and send back whatever response you want from your server From the client you'd be missing caching but yeah. It's a completely different story in the server.
- satvikpendem 4y agoYeah on the client side, it depends on the client but many can cache your queries for you, I know Relay does this pretty well.
- cratermoon 4y agoThe n+1 problem with graph representations of non-graph data is so common it begs for a solution in the core of the design, not as something added on or a "best practice" like dataloaders. It worked for Facebook when they created GraphQL because they already had the backend shaping the data into a Facebook social graph. Everyone else is probably using relational data, and I have personal experience with the pain of manually coding around N+1 for every instance.