5 ms·

I've seen many mobile developers be frustrated at constantly needing to ask the backend developers to make new rest endpoints for them because the existing ones

by m12k 7y ago

I've seen many mobile developers be frustrated at constantly needing to ask the backend developers to make new rest endpoints for them because the existing ones were not exposing the data in the way they needed it exposed. And similarly I've seen backend devs be frustrated at continually having to make new endpoints for those nagging mobile devs. If you have teams working independently of one another, where the backend team is providing a service to the frontend team(s), it makes sense to use a tool like GraphQL to able to go "here's access to anything you need - go ahead and use it however you need" instead of needing to keep coming back and building new endpoints again and again. If you're the one both creating and consuming the endpoints, then sure, it doesn't matter where you write your query, and building abstractions to move the query all the way out to the client is a waste of time.

lhorie 7y ago
> here's access to anything you need - go ahead and use it however you need But that's almost never what you want: as the backend developer, it's one's job to care about security and the performance of queries. As far as I know there's no straightforward way of automagically translating every possible permutation of SQL query primitives into GraphQL primitives in a way that is intuitive to a frontend developer, reasonably performant and secure, so at some point the backend dev has to step in and do the work of connecting the GQL layer to the SQL layer.
- krschultz 7y ago
  I'd say that that you can generalize fulfilling the queries and making them secure. It's not easy to generalize making them performant. But you can be more reactive on performance, when a query becomes a problem you break out of the general system and write something optimized.
earthboundkid 7y ago
It seems that the problem that GraphQL solves is Conway’s Law. For an org that can keep the backend and frontend together, it’s not much of an improvement.
- xrd 7y ago
  I would argue that I've never seen even small teams keep the backend and frontend together if they are doing anything important. GraphQL is, if nothing else, a nice layer over your data that allows the backend developers to see what the front end developer are doing better than REST. That introspection is really helpful.

by m12k 7y ago

lhorie 7y ago

> here's access to anything you need - go ahead and use it however you need But that's almost never what you want: as the backend developer, it's one's job to care about security and the performance of queries. As far as I know there's no straightforward way of automagically translating every possible permutation of SQL query primitives into GraphQL primitives in a way that is intuitive to a frontend developer, reasonably performant and secure, so at some point the backend dev has to step in and do the work of connecting the GQL layer to the SQL layer.

krschultz 7y ago
I'd say that that you can generalize fulfilling the queries and making them secure. It's not easy to generalize making them performant. But you can be more reactive on performance, when a query becomes a problem you break out of the general system and write something optimized.

earthboundkid 7y ago

It seems that the problem that GraphQL solves is Conway’s Law. For an org that can keep the backend and frontend together, it’s not much of an improvement.

xrd 7y ago
I would argue that I've never seen even small teams keep the backend and frontend together if they are doing anything important. GraphQL is, if nothing else, a nice layer over your data that allows the backend developers to see what the front end developer are doing better than REST. That introspection is really helpful.