So it's a clean abstraction layer? Is that abstraction layer easy to understand, intuitive to train new developers on, and faster to implement then traditional API approaches?
- Easy to understand? Yes, I think so. It's very easy to glean what data requirements a component has from its associated GraphQL query.
- Intuitive? Queries and subscriptions, yes. In the same sense that a React component using props is intuitive. Mutations and optimistic updates are maybe marginally less intuitive, but not prohibitively so.
- Faster to implement? Client-side, absolutely, as there's no need to think about how to retrieve data, you just declare what you want, and Apollo fetches what's necessary. It can also keep track of subscriptions / cache invalidation. Server-side, definitely not. The n+1 problem is tougher than with REST + SQL, and it's harder to make single round trips to the DB to fetch nested data.
Comments
The main value prop for me with GraphQL is that it makes data a composable, declarative dependency of a view.
So it's a clean abstraction layer? Is that abstraction layer easy to understand, intuitive to train new developers on, and faster to implement then traditional API approaches?
- Easy to understand? Yes, I think so. It's very easy to glean what data requirements a component has from its associated GraphQL query.
- Intuitive? Queries and subscriptions, yes. In the same sense that a React component using props is intuitive. Mutations and optimistic updates are maybe marginally less intuitive, but not prohibitively so.
- Faster to implement? Client-side, absolutely, as there's no need to think about how to retrieve data, you just declare what you want, and Apollo fetches what's necessary. It can also keep track of subscriptions / cache invalidation. Server-side, definitely not. The n+1 problem is tougher than with REST + SQL, and it's harder to make single round trips to the DB to fetch nested data.
There are some libraries that hell with that, namely prisma, hasura and postgraphile.