REST in Peace. Long Live GraphQL • Hacker News Board

Re: REST in Peace. Long Live GraphQL

#41

Post by t_fatus » Mon, Jul 24, 2017, 5:06 PM UTC

sametmax wrote: post #19

merb wrote: post #3

> The need to do multiple round trips to fetch data required by a view: With GraphQL, you can always fetch all the initial data required by a view with a single round-trip to the server. I'm not sure what's different. You can actually implement the same with plain old http api's, also.

You can but you have to write all the allowed query combinations. Graphql is more flexible. It's also declarative, so you can provide a widget with the schema it needs. Another benefit of graphql is that is a "lingua franka", you can use it internally, between microservices, etc.

Indeed, some of the points which I loved the most when I started using it was how it allows to avoid writing any serialization method, how it helps centralize permissions, and, as said in the article, the simplicity it adds if you want to add fields in your queries.

Re: REST in Peace. Long Live GraphQL

#42

Post by nemild » Mon, Jul 24, 2017, 5:07 PM UTC

I'm pretty disappointed by this title.

I know that it might be said in fun - and is an easy way to get clicks, but it feeds into the narrative of new, shiny tech. As the article points out at the end, there are very real engineering tradeoffs with GraphQL - and the answer isn't as easy as REST is dead, anachronistic technology that no engineer should consider (the XML analogy felt particularly inflammatory).

Kelly and I were chatting about GraphQL, and his post might be a more thoughtful engineering post: http://kellysutton.com/2017/01/02/do-we-need-graphql.html (the title - Do we need GraphQL? - is at least the way I'd expect engineers to approach the problem, where he discusses the tradeoffs)

In my MongoDB series, I point out a past case where Free Code Camp fed the hype, by telling engineers that the reason everyone had to learn the MEAN stack was due to employability in the software industry: https://medium.freecodecamp.org/the-real-reason-to-learn-the...

(you had to dig into the article to realize that their argument was more nuanced, and that they taught SQL first before MongoDB)

A number of "engineering" posts are not written as a thoughtful engineer might, and are in many ways marketing for the products sold (like a training program or code camp).

Re: REST in Peace. Long Live GraphQL

#43

Post by andrewingram » Mon, Jul 24, 2017, 5:07 PM UTC

davewritescode wrote: post #39

GraphQL only solves half the problem, how do you update resources with GraphQL?

By using mutations.

Re: REST in Peace. Long Live GraphQL

#44

Post by ruslan_talpa » Mon, Jul 24, 2017, 5:09 PM UTC

ergo14 wrote: post #35

How do people solve performance problems with GraphQL? I can imagine that it can be quite slow internally with multiple joins/subqueries in the datastore.

It depends on how you write your joins, PostgreSQL does a great job as long as you have the right indexes in place, certainly much faster than doing sequential queries.

My take on it https://subzero.cloud (GraphQL and REST api for your database), built on top of https://postgrest.com

Re: REST in Peace. Long Live GraphQL

#45

Post by t_fatus » Mon, Jul 24, 2017, 5:10 PM UTC

infogulch wrote: post #26

merb wrote: post #3

> The need to do multiple round trips to fetch data required by a view: With GraphQL, you can always fetch all the initial data required by a view with a single round-trip to the server. I'm not sure what's different. You can actually implement the same with plain old http api's, also.

Right but then you have to build a custom http api for each and every new view. Oh, and now you altered the view a tiny bit and need some more fields? Add yet another api. Oh, you did a redesign and you only need a tiny bit of data now? Either add another api again, or deal with the fact that you're wasting bandwidth by sending a bunch of unnecessary data.

or you can pass the fields you want in your request, and then realizing it would be simplier to fetch all your data in only one endpoint to avoid multiple roundtrips, create a giant request-parsing-data-fetching logic to respond with some kind of nested data, yeah GraphQL is useless because we can build a new one from scratch for each of our projects ;)

Re: REST in Peace. Long Live GraphQL

#46

Post by 18nleung » Mon, Jul 24, 2017, 5:10 PM UTC

davewritescode wrote: post #39

GraphQL only solves half the problem, how do you update resources with GraphQL?

GraphQL supports both queries to access data and _mutations_ to change data:

  mutation {
    createUser(u: "user", p: "pass") {
      u,
      p
    }
  }

Re: REST in Peace. Long Live GraphQL

#47

Post by t_fatus » Mon, Jul 24, 2017, 5:12 PM UTC

linkmotif wrote: post #34

baron816 wrote: post #17

I tried to build a GraphQL server, but found it impractical since I didn't want to use Relay or Apollo on the front end. Formatting the query strings just made a mess and was a lot of trouble considering the simple resources I needed. Dealing with authentication and authorization looked like it was going to be a headache as well. I ended up going back to REST. Should I give it another look? Was I too quick to dismiss…

Not sure if you're not going to use it with Apollo/Relay. These clients help you format queries in JS with Babel transforms. These transforms also are what help couple your front end to your back end by validating queries at front end compile time webpack bundling), which is a huge element of the charm imo.

+ they can help you implement caching strategies / offline modes

Re: REST in Peace. Long Live GraphQL

#48

Post by dperfect » Mon, Jul 24, 2017, 5:13 PM UTC

> When it comes to versioning, GraphQL has an interesting take on that. Versioning can be avoided all together. Basically, we can just add new fields without removing the old ones, because we have a graph and we can flexibly grow the graph by adding more nodes.

In my experience, versioning a RESTful API is not hard (much has been written about the various approaches). The cases when versioning does get hard usually correspond to major system architecture changes (e.g., restructuring fundamental relationships between data models), and in those cases, I suspect GraphQL wouldn't help a whole lot. You may still need to build some kind of compatibility layer to support older versions.

Other than that, adding new fields (which account for 90%+ of the changes to APIs I work on) are just as easy to add to RESTful endpoints. If payload size really does become an issue (it's usually negligible), it's easy enough to add a parameter or two to control the extent of the response data.

As for reducing round trips, I do see the advantage of using GraphQL, though to be fair, well-designed RESTful APIs can avoid excessive round trips as well - they just require a bit more coordination between client and server development (which is a good thing!). RESTful APIs also have the advantage of mutation payloads that look like their corresponding response representations.

To address some of the potential concerns with GraphQL (such as resource exhaustion), I believe it would require more development time/resources for most of the projects I've worked on - even after factoring in any technical debt brought on by RESTful API limitations.

Re: REST in Peace. Long Live GraphQL

#49

Post by t_fatus » Mon, Jul 24, 2017, 5:15 PM UTC

davewritescode wrote: post #39

GraphQL only solves half the problem, how do you update resources with GraphQL?

and in addition to mutations (which mutate data stored in the backend) you can use subscriptions to update your local data store once they changed

Re: REST in Peace. Long Live GraphQL

#50

Post by randallsquared » Mon, Jul 24, 2017, 5:15 PM UTC

As your REST API grows, you will often want to implement search endpoints, and allow queries using fields you've defined. GraphQL is just the search endpoint for your REST API, if you need to allow so much flexibility that implementing it all would be troublesome.