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?

#91

Post by CGamesPlay » Thu, Jul 19, 2018, 4:07 PM UTC

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…

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)?

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

#92

Post by infogulch » Thu, Jul 19, 2018, 4:13 PM UTC

nailer wrote: post #32

I'm holding off until I don't have to define types in 3 places: 1. TypeScript 2. Document database 3. GraphQL I know there are things that do two of these. I want all three.

graphql-tag [1] is very close to automatic typing for TypeScript. It lets you import a `x.gql` file (or whatever suffix) that contains query text directly, and translates the contained queries into named input/output types and parsed query documents based on your schema.

It's great but it's not quite perfect for me: I'd prefer if it produced a function that accepts your query executor and inputs, and returns an observable of the result, and it doesn't work very smoothly with angular (especially 5+).

[1]: https://github.com/apollographql/graphql-tag

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

#93

Post by jameslk » Thu, Jul 19, 2018, 4:15 PM UTC

GraphQL really shines for querying data, but if you do a lot of writing of data, the API starts to feel like a clumsy version of RPC. I ran into this trying to apply GraphQL to a business use case that required lots of user input. Designing mutations on both the client and the backend is pretty tedious, especially when it comes to handling the response of the mutation. For example, there's no straight forward way to handle errors like what's commonly done with REST using HTTP error codes.

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

#94

Post by schickling » Thu, Jul 19, 2018, 4:17 PM UTC

Almost all developers/team who actually tried out and used GraphQL, will say the same thing: You never want to go back.

Most of the arguments against GraphQL that I'm reading here, seem to actually be misconceptions (or the GraphQL ecosystem not being far enough yet).

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

#95

Post by kej » Thu, Jul 19, 2018, 4:19 PM UTC

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.

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

#96

Post by syrusakbary » Thu, Jul 19, 2018, 4:21 PM UTC

haney wrote: post #10

Mostly, NOTE: I'm using python/django/graphene server side and apollo client side. I love how flexible it is for client developers and because the great client side libraries it helps to eliminate a ton of boiler plate code on the client side. My biggest complaint has been "lost" exceptions and caching. Because it's possible for an exception to be thrown server side on one field while the other ones succeed I've been…

That's great feedback. I'm working on vastly improving exception reporting for the next version of Graphene :)

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

#97

Post by misterbwong » Thu, Jul 19, 2018, 4:22 PM UTC

ilovecaching wrote: post #29

ilovecaching wrote: post #22

Absolutely. Before GraphQL we were making a monumental effort to build a REST API. After deliberating on exactly what REST was and how we’d represent a few red haired resources, we were spending a lot of client time fetching deep trees through resource links. When we moved to GraphQL it solved a lot of the administrative and philosophical headaches and considerably reduced the number of connections, wasted data, and…

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.

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

#98

Post by bradhilton » Thu, Jul 19, 2018, 4:26 PM UTC

Yes, our team has migrated to GraphQL and it has been great, both on the front and backend.

We have a Django app on the backend and have used Django REST Framework for our REST API. That was a great experience, but had some limitations. We've written our new GraphQL API with the help of Graphene and it has been awesome. Everything is very declarative and exploring the API schema couldn't be easier using GraphiQL.

Implementing it on the frontend has been great too. Yes, you do have to specify what fields you want, but having complete control is worth the extra boilerplate. I'd recommend it heartily.

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

#99

Post by hrktb » Thu, Jul 19, 2018, 4:27 PM UTC

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.

> the client dictates its own requirements, and the server is able to respond with no more and no less than what the client requires.

The burden of dictating specs is just shifted around, and it seems the workload on the server side is bigger with h GraphQL (wider range of cases to handle).

Am I missing something ?

> REST necessitates multiple queries

This is a self imposed limitation at best

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

#100

Post by jonotime » Thu, Jul 19, 2018, 4:28 PM UTC

Another django/graphene shop here. I'm really enjoying the transition. My one complaint is with deep queries. If the query asks for a very nested objects, the amount of DB fetches can become large and then you get a performance hit. With REST you generally know the performance of your queries since the schema is static. How do people solve the n + 1 issue here?