Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

171–180 of 182 posts

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

#171

Post by tomnipotent »

alexchamberlain wrote: post #139
tormeh wrote: post #135

Earlier quoted context omitted.

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

> the GraphQL schema should be your point of stability, whereby anything in front or behind can change

This is the bit of abstraction I see most developers fail to understand when evaluating GraphQL.

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

#172

Post by [deleted] »

misterbwong wrote: post #97
ilovecaching wrote: post #29

Earlier quoted context omitted.

I should also mention that we finished our migration ahead of schedule. It was super easy to have GraphQL alongside REST, and we quickly iterated on converting each rest call to graphQL. We’ve also found that on boarding our new hires is much simpler. There’s a lot of misinformation about REST, and we were having to retrain people, and when they wanted to see our schema we would then have to teach them swagger as wel…

Out of curiosity, what does "tech them swagger" entail? I was under the impression that most of it was automated and that it's more of a standard than an implementation.

[deleted]

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

#173

Post by invisible »

pandeiro wrote: post #152
ericcoleman wrote: post #111

Earlier quoted context omitted.

You don't have to use anything other than `fetch` to consume a graphql API.

Right, then you basically lose caching, since the everything's-a-POST requests would go to the wire every time. Not that I haven't considered making that trade-off.

You can use GET if you want (since GraphQL is still just over HTTP). The implementation can largely be up to you (like REST) if you want, but you get loads of things already if you opt into some opinions that libraries have established (e.g. Apollo).

See https://graphql.org/learn/serving-over-http/

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

#174

Post by valw »

UncleEntity wrote: post #129
valw wrote: post #84

We migrated most of our backend (written in Clojure) from REST to GraphQL (actually a homemade alternative to GraphQL, but not relevant to this discussion). It went well, it greatly simplified both our backend and frontend code. The backend code got simpler and more stable because it no longer had to deal with "data packaging". The frontend code became more transparent, because you can now easily read what data gets…

> it repeated the SQL mistake of exposing a query language based on text, not data structures. Now we have to write queries as templates instead of assembling them programmatically. Out of curiosity couldn't you just treat queries as a composable AST and "compile" the query text from that?

> Out of curiosity couldn't you just treat queries as a composable AST and "compile" the query text from that?

You could write such a wrapper, but it won't be standard, which means that there will never be a robust library ecosystem and set of practices that arises from that. If GraphQL was to evolve, you also wouldn't be sure your wrapper can express all of GraphQL. Finally, this would add new practical hurdles, like a new dependency, additional runtime cost of compilation, obscured source mapping, etc.

Meanwhile, because GraphQL is just a text-based DSL, most people don't have a clear idea of the _information model_ of GraphQL queries - you have to read the spec to get this idea. If we are to build a robust ecosystem on top of GraphQL, this information model should be evident in the API.

All these problems are present, and very damaging, in SQL.

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

#175

Post by t_fatus »

kej wrote: post #95
t_fatus wrote: post #63

I'd like to add that correctly designed resolvers allow you: - to control very easily who can fetch what where it's fetched (permissions) - to fetch nested data when you need it without writing serializers - to help your frontend team find what they are looking for without asking the backend team everytime - mutations are a huge plus when it comes to standardization of your API too FYI we're using it in production ov…

>to control very easily who can fetch what where it's fetched (permissions) This is a piece of GraphQL I haven't been able to get my head around. Could you elaborate or point me to a good explanation of how this is implemented? Everything I found when I looked into GraphQL previously was something like "you control access to individual resources in your business layer" but never explained how .

as sgdesign said, you can write your own resolver function (which allows you to retrieve a particular field deep in the nested graph of graphql). It's very easy to create decorators to handle the usual permission cased on the field level.

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

#176

Post by t_fatus »

alexchamberlain wrote: post #156
t_fatus wrote: post #66

Earlier quoted context omitted.

One important thing to note: performance-wise, both in front-end when used with apollo, and in backend (you need to handle nested queries smartly) a good implementation of a REST api would probably be faster / lighter, but it should be largely enough for any web-app / web-service used by human beings ;)

Citation needed; what is your evidence for such an assertion?

Graphql and apollo add some overhead to your queries, both in your client and your API. And since you're still performing a POST query with each graphql query it's kinda logical to see that pure / well designed REST can outperformed graphql (if you know exactly what you want to return you don't have to run through the graphql schema / node / resolver to get the value your looking for)

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

#177

Post by yencabulator »

pandeiro wrote: post #152
ericcoleman wrote: post #111

Earlier quoted context omitted.

You don't have to use anything other than `fetch` to consume a graphql API.

Right, then you basically lose caching, since the everything's-a-POST requests would go to the wire every time. Not that I haven't considered making that trade-off.

You can make your queries ride over GET very easily, using just fetch.

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

#178

Post by krainboltgreene »

jerf wrote: post #44
krainboltgreene wrote: post #38

Earlier quoted context omitted.

> considerably reduced the number of connections, wasted data, and made our client code so much simpler through easily grokked queries. I mean, you could have also just done this with what you had.

With a standard REST interface, you have to name all such combinations in advance. Possibly build custom code for each. With GraphQL, you specify them all at once, and are guided towards implementing code that will handle that. (There's no magic in GraphQL, of course, but the conceptualization alone can be useful. And if you're already in some particular ecosystem, they may have some localized magic you can use.) You…

> With a standard REST interface

There's no such thing.

> you have to name all such combinations in advance.

No you don't.

> Possibly build custom code for each.

As much as any other API.

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

#179

Post by krainboltgreene »

jerf wrote: post #45
krainboltgreene wrote: post #41

Earlier quoted context omitted.

> Everything else is line noise. It's always weird to see this type of thing on HN. How anyone can call the way the web works "line noise" is baffling to me.

Fundamentals vs. changing tech. "Idempotency" as a concept is fundamental. Which header means what for some cache layer is not. REST unavoidably has a lot of things in it that are changing tech. (Nominally, it has a lot of fundamentals in it too, but per the other REST discussion on the homepage, which fundamentals it encompasses seems to vary on a person-by-person basis.)

Most of the REST understanding is basically "how do distributed caches work?".

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

#180

Post by krainboltgreene »

ilovecaching wrote: post #69
krainboltgreene wrote: post #38

Earlier quoted context omitted.

> considerably reduced the number of connections, wasted data, and made our client code so much simpler through easily grokked queries. I mean, you could have also just done this with what you had.

Not really. With REST, the server dictates the minimum requirements of the client. In GraphQL, the client dictates its own requirements, and the server is able to respond with no more and no less than what the client requires. Also REST necessitates multiple HTTP queries to fetch multiple resources. This is not a requirement of GraphQL.

> With REST, the server dictates the minimum requirements of the client.

Says who?

> Also REST necessitates multiple HTTP queries to fetch multiple resources.

Again, says who?

Post reply on HN