Ask HN: Were you happy moving your API from REST to GraphQL? • Hacker News Board

Re: Ask HN: Were you happy moving your API from REST to GraphQL?

#131

Post by xrd » Thu, Jul 19, 2018, 6:17 PM UTC

I'm really curious to hear from people dealing with massive JSON (or XML) responses via REST. This is where REST really falls apart with complexity that is much worse than trying to learn the complexity of GraphQL.

See: https://brandur.org/graphql

"In GraphQL, every contract is explicit and observable. Providers can use something like a canonical log line to get perfect insight into the fields that are in use for every request, and use that information to make decisions around product development, API changes, and retirement."

You simply cannot know with a REST API what to remove if the decisions on what to return for a request are largely made by the server side team. So, you end up with massive, clunky and confusing responses. GraphQL forces the client side users to understand how to use it, and because of that you get so much more.

Re: Ask HN: Were you happy moving your API from REST to GraphQL?

#132

Post by iteriteratedone » Thu, Jul 19, 2018, 6:17 PM UTC

One question I have and for my general attitude towards new web tech for the past 5 years... why would you think it would be better

These type of opinionated takes on old tech are mostly hype and rarely offer something truly new. If you are an engineer and were forced to take this on you should ask yourself if your team really cares about good engineering

Re: Ask HN: Were you happy moving your API from REST to GraphQL?

#133

Post by chillacy » Thu, Jul 19, 2018, 6:18 PM UTC

CuriousSkeptic wrote: post #117

Zyst wrote: post #73

Earlier quoted context omitted.

>we were spending a lot of client time fetching deep trees through resource links >it solved a lot of the administrative and philosophical headaches >considerably reduced the number of connections >considerably reduced wasted data >made our client code so much simpler through easily grokked queries I feel that grandparent does contain information which might be valuable for adoption.

My interpretation was: “We did ReST trying to follow dogma and ended up with a badly designed API that din’t fit our needs. Switching to a tech with less dogma on how to do things led us to a better API-design with a better fit” (inferring some context from my own experience here, could be wrong) In the end I would guess you can end up in a similar place with a standard fetch-json design if you just ignore ReST dogma…

For reference we’re switching from the non dogmatic get/post requests over http to graphql and it’s been equally good for us too for different reasons.

Re: Ask HN: Were you happy moving your API from REST to GraphQL?

#134

Post by chacham15 » Thu, Jul 19, 2018, 6:23 PM UTC

schrockn wrote: post #121

Nick Schrock here, one of the GraphQL co-creators. I agree with a lot of the criticism in terms of the difficulty of implementing GraphQL backends. I think there's a big opportunity for folks to build vertically integrated toolkits that deal with N+1 issues, integrate DataLoader natively and so forth. Good versions of these would deal with a lot of issues described here in greenfield GraphQL backends. I talked about…

My largest criticism of GraphQL is that it doesnt go far enough. That is to say that I want my components to declare their data dependencies, but not all data comes from a server. Some data is computed, other data comes from different servers, and some other data is locally generated. For example, facebook has some user information that I want to add to my User object; in my case, theres no reason for the component to know that its data is actually coming from multiple sources but I have no simple way of coding that.

Another issue: there currently are a lot of servers that are REST and it would be really nice if there were ways of incorporating them in the GraphQL schema. One of the most useful features to add here would be ways of linking separate REST objects to each other in the GraphQL schema. This would help adoption quite a bit.

Re: Ask HN: Were you happy moving your API from REST to GraphQL?

#135

Post by tormeh » Thu, Jul 19, 2018, 6:27 PM UTC

StavrosK wrote: post #105

CGamesPlay wrote: post #91

Earlier quoted context omitted.

Why do you think it makes the most sense if “the backend and frontend teams don't like to talk to each other”, given that your biggest complaint seems to be “I don't want to spend time figuring out your database schema“? Aren’t you the frontend guy in this scenario, and not wanting/able to talk to the backend guys (the people who designed the database schema)?

He (the hypothetical he) doesn't want to talk to them to get them to add the endpoint he needs, so he'd prefer to just get the schema directly and query for whatever.

Note that this means the back end team has to keep the schema backwards compatible forever. Having everyone have direct access to the schema (speaking from SQL experience) is bad. This is the start of a slow moving disaster train that you can't stop.

Re: Ask HN: Were you happy moving your API from REST to GraphQL?

#136

Post by RussianCow » Thu, Jul 19, 2018, 6:27 PM UTC

MattyRad wrote: post #115

Androider wrote: post #78

As a consumer of APIs I vastly prefer REST APIs. In my opinion, GraphQL moves too much of the burden to the user of the API. It makes most sense if the data is highly dynamic, you have a mobile app and every call is expensive, or (and this seems more common) the backend and frontend teams don't like to talk to each other. As a user, I just want to GET /foo, with a good old API token I pasted from your dev docs, and m…

This is my experience as well. We briefly worked with GraphQL for one of our smaller projects. One of the biggest shortcomings of the API we created was that there was an incredibly large learning curve for teams/people not interested in using GraphQL. Instead of using the sensible features of GraphQL queries, the other team consuming our API were writing the most verbose queries they possibly could, not utilizing an…

That's interesting, because as a frontend engineer, I find most RESTful APIs to introduce more "needless hassle", mostly in the form of making me send multiple requests to get data multiple levels deep and then consolidating it on the frontend, rather than just sending me what I want to begin with.

I agree with query building being tedious, though I'm working on a query builder helper library to make this less painful. Hopefully at some point I can open source it.

Re: Ask HN: Were you happy moving your API from REST to GraphQL?

#137

Post by RussianCow » Thu, Jul 19, 2018, 6:31 PM UTC

tormeh wrote: post #135

StavrosK wrote: post #105

Earlier quoted context omitted.

He (the hypothetical he) doesn't want to talk to them to get them to add the endpoint he needs, so he'd prefer to just get the schema directly and query for whatever.

Note that this means the back end team has to keep the schema backwards compatible forever. Having everyone have direct access to the schema (speaking from SQL experience) is bad. This is the start of a slow moving disaster train that you can't stop.

Not forever, just as long as you support out-of-date clients (either because of cached JS on the web, or mobile apps that haven't been updated recently). Plus, you generally don't want to introduce backwards-incompatible changes to your schema anyway at a certain scale, unless you can afford to have planned downtime, so GraphQL doesn't add anything new here.

Re: Ask HN: Were you happy moving your API from REST to GraphQL?

#138

Post by schrockn » Thu, Jul 19, 2018, 6:35 PM UTC

chacham15 wrote: post #134

schrockn wrote: post #121

Nick Schrock here, one of the GraphQL co-creators. I agree with a lot of the criticism in terms of the difficulty of implementing GraphQL backends. I think there's a big opportunity for folks to build vertically integrated toolkits that deal with N+1 issues, integrate DataLoader natively and so forth. Good versions of these would deal with a lot of issues described here in greenfield GraphQL backends. I talked about…

My largest criticism of GraphQL is that it doesnt go far enough. That is to say that I want my components to declare their data dependencies, but not all data comes from a server. Some data is computed, other data comes from different servers, and some other data is locally generated. For example, facebook has some user information that I want to add to my User object; in my case, theres no reason for the component t…

I'd check out Apollo for these use cases. They allow a client GraphQL schema to be sourced from a bunch of different places, including (I believe) local-only state, REST APIs, and others. See https://www.apollographql.com/docs/link/links/rest.html

Re: Ask HN: Were you happy moving your API from REST to GraphQL?

#139

Post by alexchamberlain » Thu, Jul 19, 2018, 6:35 PM UTC

tormeh wrote: post #135

StavrosK wrote: post #105

Earlier quoted context omitted.

He (the hypothetical he) doesn't want to talk to them to get them to add the endpoint he needs, so he'd prefer to just get the schema directly and query for whatever.

Note that this means the back end team has to keep the schema backwards compatible forever. Having everyone have direct access to the schema (speaking from SQL experience) is bad. This is the start of a slow moving disaster train that you can't stop.

I disagree; the GraphQL schema should be your point of stability, whereby anything in front or behind can change. That being said, ofc, you'll need to deprecate something at some point and that is fine, it might just take a couple of weeks. See @deprecated decorator examples

Re: Ask HN: Were you happy moving your API from REST to GraphQL?

#140

Post by kimdotcom » Thu, Jul 19, 2018, 6:39 PM UTC

valw wrote: post #87

jaequery wrote: post #17

my experience is just ok. as someone here puts it, great for frontend devs but bad for backend devs. if you have db schemas on the backend if using orm, get ready to duplicate them again for graphql. and on the frontend, get prepared to write out every songle fields you need from the backend. i can imagine it may be brutal for those who have a lot of changes in their schemas. my conclusion is that, since im a fullsta…

> if you have db schemas on the backend if using orm, get ready to duplicate them again for graphql. I would consider this a weakness of ORMs, not of GraphQL.

The Vietnam of CS.