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

31–40 of 182 posts

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

#31

Post by jaegerpicker »

DiabloD3 wrote: post #25

The problem with REST is largely the people who look at it blindly as "thing that makes the CRUD go" instead of as a methodology of how to effectively use HTTP verbs and designing URIs that make sense. So I guess my question is, why would I use GraphQL over, say, the Swagger tool suite? Swagger and the OpenAPI spec defines a way of doing REST that best fits both what Roy Fielding meant for REST but also fits IDE and…

There are HUGE benefits for our client developers with GraphQL. Like being able to select as much or as little as a particular view/component/whatever requires and no more. GraphQL from a front end or mobile POV makes your api more like a data store that it can interact with and query for it's needs, which makes app UI work much nicer.

There are also a ton of maintenance benefits, like for example if you add a field in GraphQL that's perfectly fine to not change the version because that break any existing calls, which is not always true with REST.

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

#33

Post by arnorhs »

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…

you should take a look at the caching policies (fetch policy) apollo client provides as well as the error policy. neither are easy to find

for the error policy, you basically control the behavior (for each client instance or each request) when a request is considered failed. none, ignore and all. [1]

fetch policy allows you immense control over caching. this all depends on what you're doing but in some instances it can even make sense to never cache any requests, depending on how you application is structured. the docs are hard to google for this, but here's a link for you [2]

[1] https://www.apollographql.com/docs/react/features/error-hand...

[2] https://www.apollographql.com/docs/react/api/react-apollo.ht...

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

#34

Post by minor3rd »

IBCNU wrote: post #18

Not at all (we rolled our own back end). The added complexity of building queries to join our API ended up creating such a quagmire of SQL that any dev coming in will basically have to learn our own custom ORM.

Sounds like you had a few problems.

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

#35

Post by mej10 »

We have, so far, only made a GraphQL endpoint for internal use. It has been awesome for quickly finding things in a medium-complexity database schema (30 or so tables, bunch of different relationships). It has become my preferred way to quickly find things in the database.

That being said, there are cases where a join between ad hoc subqueries is the best way, and GraphQL doesn't really offer a way to do that (though I don't see why it wouldn't be possible). E.g. arbitrarily combining two GraphQL queries that return lists where some field in one is equal to some field in another.

But in terms of replacing REST, where you have to do all of that anyway, it is far and away the better option (for ad hoc querying, at least).

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

#37

Post by krainboltgreene »

jaegerpicker wrote: post #31
DiabloD3 wrote: post #25

The problem with REST is largely the people who look at it blindly as "thing that makes the CRUD go" instead of as a methodology of how to effectively use HTTP verbs and designing URIs that make sense. So I guess my question is, why would I use GraphQL over, say, the Swagger tool suite? Swagger and the OpenAPI spec defines a way of doing REST that best fits both what Roy Fielding meant for REST but also fits IDE and…

There are HUGE benefits for our client developers with GraphQL. Like being able to select as much or as little as a particular view/component/whatever requires and no more. GraphQL from a front end or mobile POV makes your api more like a data store that it can interact with and query for it's needs, which makes app UI work much nicer. There are also a ton of maintenance benefits, like for example if you add a field…

> There are HUGE benefits for our client developers with GraphQL. Like being able to select as much or as little as a particular view/component/whatever requires and no more.

That's not a unique benefit of GraphQL. Any HTTP based API can do this, regardless of how it's designed.

Some specifications even have it baked in (See: jsonapi.org).

> GraphQL from a front end or mobile POV makes your api more like a data store that it can interact with and query for it's needs, which makes app UI work much nicer.

Again, not unique to GraphQL.

> There are also a ton of maintenance benefits, like for example if you add a field in GraphQL that's perfectly fine to not change the version because that break any existing calls, which is not always true with REST.

Again...

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

#38

Post by krainboltgreene »

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…

> 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.

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

#39

Post by bpicolo »

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.

There are stacks that can give you delicious sharing here. Clojure/clojurescript with Lacinia[0] for example could lead to something pretty terrific, as Clojure DB access is all immutable structs instead of activerecord-style stuff.

[0]: https://github.com/walmartlabs/lacinia

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

#40

Post by nailer »

mlevental wrote: post #36
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.

which two?

Usually 2 and 3.

Sometimes 1 and 3 (see http://avant.engineering/graphql-and-typescript/)

Post reply on HN