4 ms·
I'm intrigued ... can you elaborate on the wow factor beyond REST that you see in GraphQL? When I looked at it in the past, it seems to make sense for things th
by tostitos1979 9y ago
I'm intrigued ... can you elaborate on the wow factor beyond REST that you see in GraphQL? When I looked at it in the past, it seems to make sense for things that could be represented by graph (e.g. FB's social graph), and graphql allowed you to run complex operations in the backend without fetching each individual node on the client. I clearly missed something?
- lolive 9y agoAnd if you can also elaborate on why SPARQL and RDF were a major failure, and how GraphQL is different/better?
- amirouche 9y ago> it seems to make sense for things that could be represented by graph False, even if there is graph in its name it's not restricted to graph, and that what is great about it compared to things like RDF and SPARQL. Backend data can be stored in key/value store, document, files, RDBMS or whatever. And you will still be able to make it work. AFAIK you write a "translation" layer that interprets a pseudo-JSON file into your data. AFAIK GraphQL is not good at querying recursive datastructure, it's better at "neighborhood" kind of query, so you can traverse Foreign Keys, but not "indefinitely". > graphql allowed you to run complex operations in the backend without fetching each individual node on the client. Yes. > I clearly missed something? IDK. For me, GraphQL basically it's an RPC interface particularly suited at "reading" data. > And if you can also elaborate on why SPARQL and RDF were a major failure, and how GraphQL is different/better? GraphQL is not tied to particular data layout. I don't know much of SPARQL and RDF actually and don't know why they failed. I am just guessing. That said, GraphQL it "just" another query language, it's "just" another DSL targeted at querying datastructures. As something that was thought a long time, focused to solve a particular issue.
- scottmf 9y ago> AFAIK GraphQL is not good at querying recursive datastructure, it's better at "neighborhood" kind of query, so you can traverse Foreign Keys, but not "indefinitely". That isn't true. You can request data in any shape you want and could theoretically traverse through child nodes indefinitely. We have many queries which go 5-6 levels deep.
- lolive 9y agoHow do you deal with IDs misalignment between data sources?
- scottmf 9y agoCould you clarify what you mean? Got an example?
- lolive 9y agoLet's say you want to query Wikipedia for village descriptions, and get a map of matched villages from openstreetmap. Would it be a use case where GraphQL could help? Then it would need a "translation" layer for both systems. And joins between datasets would be based (for example) on the couple "country+postalCode". Is it a possible use case of GraphQL?
- scottmf 9y agoCould you show me a quick example of what a request and response would look like with REST? I'm still not quite sure what you mean.
- lolive 9y agoOk. And the join strategy (i.e IDs alignment) between data sources is defined (declaratively? Programmatically?) in the "translation" layer. Sounds very interesting. I still think the URIs of the semantic web are a better idea, but given the fact that nobody (re)uses them, then why not a "translation" layer.
- arstin 9y agoThis frontend code. const ProfileImage = ({ user }) => <img src={user.avatarUrl} alt={user.name} />; const query = gql`{ user(id: 3) { name avatarUrl } }` export const ProfileImageWithData = graphql(query)(ProfileImage); You can ask for data in the structure the UI expects and only get exactly that data, letting the GQL client handle batching network requests for needs distributed across the whole app, caching, UI updating, etc under the hood. Also does a great job of decoupling product and data management code.