4 ms·

>If anything I think the biggest problem with GraphQL is that, if people just saw it is a simple alternative to REST, with a well defined set of query (GET) and

>If anything I think the biggest problem with GraphQL is that, if people just saw it is a simple alternative to REST, with a well defined set of query (GET) and mutation (PUT/POST/DELETE) endpoints, they wouldn't get caught up in all this "infinite object graph" stuff that I never hit in my day-to-day. But isn't this "infinite object graph" like the only real valuable part of GraphQL? People get caught up on that because all the other things you mention aren't really an issue with normal REST API. If you're saying you use GraphQL but don't use the key defining feature of GraphQL. Then what's the point of using GraphQL if you're just using a strict predefined set of things you can query/mutate?

scotty79 3y ago
Value of GraphQL imho is the ability for the api to be driven by frontend requirements without bothering the backend guys "to expose that one field in that one query". Once the app is developed I think you might put up reasonable general limits to what queries are responded to in a general manner over the whole api.
- OJFord 3y ago
  So you move the issue to the resolver instead? IMO graphql is trying to allow the frontend to be the 'driver', the first bit; otherwise you just have the backend publish an API and then that is what it is, if that one field is available from a different endpoint than the one you're currently using, that's the one you need to hit (as well), tough. Not to say either way around is inherently better, I just see it as a switch from backend-driven to frontend-driven. (Personally I'd love to use something like OpenAPI, with tooling more mature than probably exists, to be properly schema-driven, with both backend and frontend stubs/clients derived from that.)
  - scotty79 3y ago
    > So you move the issue to the resolver instead? Yes. Where it can be logged, inspected and dealt with wholesale. It's moveing a problem from intra-team verbal communication into software where it can be dealt with more efficiently with software tools and methods. > Not to say either way around is inherently better, I just see it as a switch from backend-driven to frontend-driven. Yes. I think that's the whole point and main benefit of GraphQL which makes a lot of sense since apps that evolve through their development usually have most changes UI driven.
    - OJFord 3y ago
      > Where it can be logged, inspected and dealt with wholesale. Just as it could be in the backend? I don't follow that point. > apps that evolve through their development usually have most changes UI driven. That's a fair point certainly, but isn't completely generalisable - if you offer a third-party API at all (or think you might) then maybe don't special-case your own frontend.
      - scotty79 3y ago
        > Just as it could be in the backend? I don't follow that point. GraphQL server is the part of the backend. The problem is that client has a new requirement, it is verbally communicated through UI change request. Frontend team implements the change then has to make a verbal request to the backend team for new data to be exposed. There's a bit of back and forth, testing. Everybody waits for everybody. It all takes time and is most of the time brainless busywork. GraphQL makes it so that request to the backend team doesn't need to be verbal (jira is same as verbal for me). It can be mediated through software and even fulfilled automatically if the GraphQL server is open enough during development. The cost of that streamlining is that at some point security or performance issues might arise, but those then can be dealt with solely by the backend and db team, as they should be because frontend is always insecure. > if you offer a third-party API at all For one such app 99 have both server and the client developed in sync. And even then with offering third party api I think it's way easier to fall into the trap of special-casing your frontend with poorly designed REST than with GraphQL, althought there might be performance and security challenges as there always are with anything public. So there might be a bit to learn about how to deal with that in GraphQL ecosystem.
        troupo 3y ago
        > It can be mediated through software and even fulfilled automatically if the GraphQL server is open enough during development. You pretend that GraphQL is magic. If there's requirement not exposed by the GraphQL server, the way to add it is literally exactly the same as for any other backend API.
- Hippocrates 3y ago
  This is how I have interpreted its value, and frontend devs have very plainly advocated for its use with this argument. I think this is a really silly value prop. Behind the elegance of a query language that lets you get your perfect little payload, there is a complex server that could need to resolve and block on requests to multiple backends, touch different caches and databases, and do joins and sorts and projections. Front end devs will add the videoRating field and have no idea that this comes from a separate API and causes the response time to double. Developing some gragantuan do-it-all meta API as a sandbox for frontend engineers is a terrible idea. You don't just slap a graph over your APIs and call it done. The GraphQL server is orders of magnitude more complex than a purpose-built API. Ultimately once the FE devs have crafted their query to satisfaction it will hardly ever change. It's better to work together and decide whats needed and how to best get that data to your app. I really favor collaboration on purpose built APIs than gargantuan do-it-all systems.
  - swyx 3y ago
    > Ultimately once the FE devs have crafted their query to satisfaction it will hardly ever change this makes the fallacy that it is FE devs driving change. it is not. it is product management. and to them (and indirectly to you), making it easy to make performant changes without 3 committee meetings is a Good Thing
  - tadfisher 3y ago
    "Driven by frontend requirements" is how approximately all APIs in the world are developed. The problem GraphQL exposes, and makes extremely punishing when you ignore it, is that of poor communication of requirements. Put it this way: you _could_ build a GraphQL resolver by means of mirroring your database schema or service structure, and let frontend engineers play in that sandbox while patching up holes. This would have the exact same result as building a REST API service that proxies requests to a SOA without understanding the performance or stability impact. Or the exact same result as exposing multiple REST services that must all be hit to render a single screen on the frontend, except you push the blocking to clients, which is not a proper solution if you care about the energy usage you don't pay for. In all of these cases, the common thread is that the backend and frontend teams aren't working together and thinking of the entire product as a system instead of a frontend/backend split. GraphQL forces you to reason about the entire system and not a series of API calls, which can obviously cause problems with siloed teams. This means I disagree with folks who attribute the power of GraphQL to "frontend-driven" APIs. Your frontend and backend is your product, so ultimately you must reckon with the boundary layer between the two.
- jameshart 3y ago
  So this completely contradicts your GP post who says the fact that it supports generic queries is not the point of GraphQL. So which is it?
  - scotty79 3y ago
    Generic during development. Once the dust settles you can restrict to what's used.
- throwaway2990 3y ago
  If you have 1, maybe 2 front ends then this is flat out laziness. The front end arguement makes sense for someone like Facebook who has many different front ends and integrations. It’s unmaintainable to try do this any other way.

scotty79 3y ago

Value of GraphQL imho is the ability for the api to be driven by frontend requirements without bothering the backend guys "to expose that one field in that one query". Once the app is developed I think you might put up reasonable general limits to what queries are responded to in a general manner over the whole api.

OJFord 3y ago
So you move the issue to the resolver instead? IMO graphql is trying to allow the frontend to be the 'driver', the first bit; otherwise you just have the backend publish an API and then that is what it is, if that one field is available from a different endpoint than the one you're currently using, that's the one you need to hit (as well), tough. Not to say either way around is inherently better, I just see it as a switch from backend-driven to frontend-driven. (Personally I'd love to use something like OpenAPI, with tooling more mature than probably exists, to be properly schema-driven, with both backend and frontend stubs/clients derived from that.)
- scotty79 3y ago
  > So you move the issue to the resolver instead? Yes. Where it can be logged, inspected and dealt with wholesale. It's moveing a problem from intra-team verbal communication into software where it can be dealt with more efficiently with software tools and methods. > Not to say either way around is inherently better, I just see it as a switch from backend-driven to frontend-driven. Yes. I think that's the whole point and main benefit of GraphQL which makes a lot of sense since apps that evolve through their development usually have most changes UI driven.
  - OJFord 3y ago
    > Where it can be logged, inspected and dealt with wholesale. Just as it could be in the backend? I don't follow that point. > apps that evolve through their development usually have most changes UI driven. That's a fair point certainly, but isn't completely generalisable - if you offer a third-party API at all (or think you might) then maybe don't special-case your own frontend.
    - scotty79 3y ago
      > Just as it could be in the backend? I don't follow that point. GraphQL server is the part of the backend. The problem is that client has a new requirement, it is verbally communicated through UI change request. Frontend team implements the change then has to make a verbal request to the backend team for new data to be exposed. There's a bit of back and forth, testing. Everybody waits for everybody. It all takes time and is most of the time brainless busywork. GraphQL makes it so that request to the backend team doesn't need to be verbal (jira is same as verbal for me). It can be mediated through software and even fulfilled automatically if the GraphQL server is open enough during development. The cost of that streamlining is that at some point security or performance issues might arise, but those then can be dealt with solely by the backend and db team, as they should be because frontend is always insecure. > if you offer a third-party API at all For one such app 99 have both server and the client developed in sync. And even then with offering third party api I think it's way easier to fall into the trap of special-casing your frontend with poorly designed REST than with GraphQL, althought there might be performance and security challenges as there always are with anything public. So there might be a bit to learn about how to deal with that in GraphQL ecosystem.
      - troupo 3y ago
        > It can be mediated through software and even fulfilled automatically if the GraphQL server is open enough during development. You pretend that GraphQL is magic. If there's requirement not exposed by the GraphQL server, the way to add it is literally exactly the same as for any other backend API.
Hippocrates 3y ago
This is how I have interpreted its value, and frontend devs have very plainly advocated for its use with this argument. I think this is a really silly value prop. Behind the elegance of a query language that lets you get your perfect little payload, there is a complex server that could need to resolve and block on requests to multiple backends, touch different caches and databases, and do joins and sorts and projections. Front end devs will add the videoRating field and have no idea that this comes from a separate API and causes the response time to double. Developing some gragantuan do-it-all meta API as a sandbox for frontend engineers is a terrible idea. You don't just slap a graph over your APIs and call it done. The GraphQL server is orders of magnitude more complex than a purpose-built API. Ultimately once the FE devs have crafted their query to satisfaction it will hardly ever change. It's better to work together and decide whats needed and how to best get that data to your app. I really favor collaboration on purpose built APIs than gargantuan do-it-all systems.
- swyx 3y ago
  > Ultimately once the FE devs have crafted their query to satisfaction it will hardly ever change this makes the fallacy that it is FE devs driving change. it is not. it is product management. and to them (and indirectly to you), making it easy to make performant changes without 3 committee meetings is a Good Thing
- tadfisher 3y ago
  "Driven by frontend requirements" is how approximately all APIs in the world are developed. The problem GraphQL exposes, and makes extremely punishing when you ignore it, is that of poor communication of requirements. Put it this way: you _could_ build a GraphQL resolver by means of mirroring your database schema or service structure, and let frontend engineers play in that sandbox while patching up holes. This would have the exact same result as building a REST API service that proxies requests to a SOA without understanding the performance or stability impact. Or the exact same result as exposing multiple REST services that must all be hit to render a single screen on the frontend, except you push the blocking to clients, which is not a proper solution if you care about the energy usage you don't pay for. In all of these cases, the common thread is that the backend and frontend teams aren't working together and thinking of the entire product as a system instead of a frontend/backend split. GraphQL forces you to reason about the entire system and not a series of API calls, which can obviously cause problems with siloed teams. This means I disagree with folks who attribute the power of GraphQL to "frontend-driven" APIs. Your frontend and backend is your product, so ultimately you must reckon with the boundary layer between the two.
jameshart 3y ago
So this completely contradicts your GP post who says the fact that it supports generic queries is not the point of GraphQL. So which is it?
- scotty79 3y ago
  Generic during development. Once the dust settles you can restrict to what's used.
throwaway2990 3y ago
If you have 1, maybe 2 front ends then this is flat out laziness. The front end arguement makes sense for someone like Facebook who has many different front ends and integrations. It’s unmaintainable to try do this any other way.