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.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.
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.