11–20 of 116 posts
Earlier quoted context omitted.
Why do you believe you need to combine them? We have a REST API and GraphQL API. They both work well for their respective use cases and together satisfy our needs.
I would like to present them to the user as "here is our API" as opposed to "here are our somewhat complementing APIs and for the one you use these docs and do this and for the other one there's the docs here and you use it differently."
Has anybody found a way to combine GraphQL and REST in a common API? I've searched but so far found no idiomatic ways to accomplish that. The reason I need REST in addition to GraphQL is that there are sometimes oddball cases where only GraphQL is a poor fit or where compatibility with older clients that I can't modify has to be ensured. Also, is there a good way to do file upload of big files with GraphQL nowadays?
For example: https://github.com/n1ru4l/graphql-schema-generator-rest
1. For instance, caching also happens on the client. This means if you reload the page, your GraphQL query will pull immediately from localStorage!
2. And then, quite important, it will be backfilled by the server with any new updates, including realtime updates that happen from other peers while the user is still using your app.
Great work on the tracing and schema support pieces! Those are certainly handy features.
How does this access control play with cache? What happens when the access control rules change?
A while ago, I wrote a real-time REST-based plugin which solves all the problems and I use it in production, it's much simpler than GraphQL. See https://github.com/SocketCluster/sc-sample-inventory
I'm surprised that more libraries aren't following the REST-based model.
Earlier quoted context omitted.
I would like to present them to the user as "here is our API" as opposed to "here are our somewhat complementing APIs and for the one you use these docs and do this and for the other one there's the docs here and you use it differently."
In that case couldn't that be done with different endpoints?
My main concern with GraphQL is access control. What happens if the user doesn't have access to part of the requested data (a subtree)... Will the GraphQL engine return an incomplete result, an inline error or will the whole query fail? What if you only want to allow showing specific fields of a resource; for example when a user requests for another user's account details, we need a way to block them from getting cer…
Can anybody explain to me how it's solving any problems? The way I see it they only move the responsibility to combine data from client to server. At the same time, you now don't just expose a couple of endpoints, you need to support a query language, which seems to impose much more effort in things like authorization. I admit I don't see the benefit.
From my experience, the biggest advantage of GraphQL is that having a well defined standard allows the community to build advanced tooling such as https://github.com/graphcool/graphql-playground by Graphcool and all the cool stuff Sashko is talking about in this presentation.
Can anybody explain to me how it's solving any problems? The way I see it they only move the responsibility to combine data from client to server. At the same time, you now don't just expose a couple of endpoints, you need to support a query language, which seems to impose much more effort in things like authorization. I admit I don't see the benefit.
Moving the responsibility of combining data to the server is a huge advantage for many organisations. It allows application developers to move much quicker and provides a common data access layer for all applications. It sounds to me like you are over-indexing on the burden placed on the backend developer in your evaluation and not considering the whole picture. From my experience, the biggest advantage of GraphQL is…
The problem is that on the way you basically reduce your server to the thin layer over DB. Exposing querying API means that you significantly lose control over what, where and how you provide from the server.
We are currently considering using GraphQL in current project and I took a long look at both the standard and library (Absinthe for Elixir). It looks terrible to me. Basically you need to provide yet another layer, supporting mostly generic operations. If your action is more then CRUD, you still need a REST API.
Moreover, you slowly lose control on what can be changed and where, your frontend basically eating logic, but unlikely to be working on it's own.
I understand that it helps when you have records with multiple associations and you want to increase performance and not load everything everywhere, but the cost appears to be huge in terms of maintenance. I totally get why FB is doing it, but it seriously worries me that they market it as an successor to REST, instead of an alternative with such-and-such tradeoffs.