3 ms·

Fair points. The thing that tipped in favor of GraphQL for the back-end was that it puts the client in charge of the data structure. I suppose you could hack so

Fair points. The thing that tipped in favor of GraphQL for the back-end was that it puts the client in charge of the data structure. I suppose you could hack something like that with REST but it would be difficult. Our application is by no means narrow or simple and GraphQL (without Redux) has been perfect. I don't dislike Redux, we just didn't need it after switching to GraphQL.

matte_black 9y ago
Could controlling the shape of the data returned by GraphQL on the client open up your application to really inefficient querying? We control what is returned in data from our REST API by merely specifying the fields you want as a parameter. If there are use cases that would require multiple tables to be joined, those are created ahead of time as views with appropriate triggers for updates and then endpoints are created for accessing that view through RESTful methods. This has always worked just fine.
- _xgw 9y ago
  Doesn't that lead to an explosion of the number of sql views and backend controllers/endpoints?
  - matte_black 9y ago
    Not at all. Not sure what other people are trying to do though.
    - joshribakoff 9y ago
      Being able to stay agile & change the app, without breaking old versions of the app, and without having to have an explosion of ad-hoc end-points for every change you've ever made. With graphQL its perfectly reasonable to never rename or delete fields, and never break backwards compatibility. With REST that would not work & would result in over-fetching, or tons of ad-hoc end points for every query you've ever written.
nawitus 9y ago
>I suppose you could hack something like that with REST but it would be difficult. Not really. You can design specific REST endpoints to return the data in the format you want.
- lparry 9y ago
  And now your frontenders need to know how to write code in whatever your backend is written in, lest every new change be bottlenecked waiting for someone to build them new endpoints. Also, your backend guys are tied up constantly doing stupid endpoint changes, and both teams are wasting time messing around with extra effort to allow one side to be deployed before the other, instead of working on actual functionality work. Doing this in REST is a genuinely unpleasant experience, well deserving of being called hacky
  - dmitriid 9y ago
    > And now your frontenders need to know how to write code in whatever your backend is written in Wat. Frontenders can write their frontend code in whatever they see fit. REST is a contract on data and format of the data between frontend and backend. > Also, your backend guys are tied up constantly doing stupid endpoint changes, and both teams are wasting time messing around with extra effort to allow one side to be deployed before the other, instead of working on actual functionality work. Well, if your teams are dysfunctional, then of course, that's what you will end up having. Now tell me: - what will you do when your glorious ad hoc GraphQL query ands up bringing the database to its knees? - what will happen when your glorious GraphQL schema doesn't have all the data the frontend needs?
    - lparry 9y ago
      > Frontenders can write their frontend code in whatever they see fit. REST is a contract on data and format of the data between frontend and backend. Oh, it’s a contract? Amazing, I guess that means you can just update the contract and nobody is stuck doing busywork anymore. Nope? I guess then either your frontenders need to learn your backend stack, lest they be stuck waiting for someone to do the busywork for them. I feel like I’m repeating myself, because I am. Please don’t quote out of context > Now tell me: > - what will you do when your glorious ad hoc GraphQL query ands up bringing the database to its knees? > - what will happen when your glorious GraphQL schema doesn't have all the data the frontend needs? Sound like interesting, challenging, and satisfying problems for the backenders to work on. Certainly more so than adding/removing fields from serialisers. These also seem like much more rare problems than the small data requirement changes that are the backbone of frontend work. I’d rather work on speeding up the things that slow down development and deal with performance when it becomes a problem. I dunno, maybe our experience differ, and in you world your app is relatively static and performance is crucial, but the world I exist in involves stakeholders constantly wanting minor changes, performance has never been a problem, and development is constantly blocking because of frontend/backend blockers on our “rest” api and capacity on either side being wasted at various times because of that blocking. Sure, sometime someone’s going to write a horrendous graphQL query where the answer is going to be “sorry, we can’t make that perfomant so we have to disallow it”, but that’s a: solvable and b: going to happen a lot less often than your frontend is going to need an extra field (or no longer need a field, but since nothing breaks these change requests rarely come through and your backend is eternally querying and sending unused data over the wire)

matte_black 9y ago

Could controlling the shape of the data returned by GraphQL on the client open up your application to really inefficient querying? We control what is returned in data from our REST API by merely specifying the fields you want as a parameter. If there are use cases that would require multiple tables to be joined, those are created ahead of time as views with appropriate triggers for updates and then endpoints are created for accessing that view through RESTful methods. This has always worked just fine.

_xgw 9y ago
Doesn't that lead to an explosion of the number of sql views and backend controllers/endpoints?
- matte_black 9y ago
  Not at all. Not sure what other people are trying to do though.
  - joshribakoff 9y ago
    Being able to stay agile & change the app, without breaking old versions of the app, and without having to have an explosion of ad-hoc end-points for every change you've ever made. With graphQL its perfectly reasonable to never rename or delete fields, and never break backwards compatibility. With REST that would not work & would result in over-fetching, or tons of ad-hoc end points for every query you've ever written.

nawitus 9y ago

>I suppose you could hack something like that with REST but it would be difficult. Not really. You can design specific REST endpoints to return the data in the format you want.

lparry 9y ago
And now your frontenders need to know how to write code in whatever your backend is written in, lest every new change be bottlenecked waiting for someone to build them new endpoints. Also, your backend guys are tied up constantly doing stupid endpoint changes, and both teams are wasting time messing around with extra effort to allow one side to be deployed before the other, instead of working on actual functionality work. Doing this in REST is a genuinely unpleasant experience, well deserving of being called hacky
- dmitriid 9y ago
  > And now your frontenders need to know how to write code in whatever your backend is written in Wat. Frontenders can write their frontend code in whatever they see fit. REST is a contract on data and format of the data between frontend and backend. > Also, your backend guys are tied up constantly doing stupid endpoint changes, and both teams are wasting time messing around with extra effort to allow one side to be deployed before the other, instead of working on actual functionality work. Well, if your teams are dysfunctional, then of course, that's what you will end up having. Now tell me: - what will you do when your glorious ad hoc GraphQL query ands up bringing the database to its knees? - what will happen when your glorious GraphQL schema doesn't have all the data the frontend needs?
  - lparry 9y ago
    > Frontenders can write their frontend code in whatever they see fit. REST is a contract on data and format of the data between frontend and backend. Oh, it’s a contract? Amazing, I guess that means you can just update the contract and nobody is stuck doing busywork anymore. Nope? I guess then either your frontenders need to learn your backend stack, lest they be stuck waiting for someone to do the busywork for them. I feel like I’m repeating myself, because I am. Please don’t quote out of context > Now tell me: > - what will you do when your glorious ad hoc GraphQL query ands up bringing the database to its knees? > - what will happen when your glorious GraphQL schema doesn't have all the data the frontend needs? Sound like interesting, challenging, and satisfying problems for the backenders to work on. Certainly more so than adding/removing fields from serialisers. These also seem like much more rare problems than the small data requirement changes that are the backbone of frontend work. I’d rather work on speeding up the things that slow down development and deal with performance when it becomes a problem. I dunno, maybe our experience differ, and in you world your app is relatively static and performance is crucial, but the world I exist in involves stakeholders constantly wanting minor changes, performance has never been a problem, and development is constantly blocking because of frontend/backend blockers on our “rest” api and capacity on either side being wasted at various times because of that blocking. Sure, sometime someone’s going to write a horrendous graphQL query where the answer is going to be “sorry, we can’t make that perfomant so we have to disallow it”, but that’s a: solvable and b: going to happen a lot less often than your frontend is going to need an extra field (or no longer need a field, but since nothing breaks these change requests rarely come through and your backend is eternally querying and sending unused data over the wire)