REST in Peace. Long Live GraphQL • Hacker News Board

Re: REST in Peace. Long Live GraphQL

#51

Post by meesterdude » Mon, Jul 24, 2017, 5:16 PM UTC

andrewingram wrote: post #23

jrs95 wrote: post #8

Earlier quoted context omitted.

Especially since avoiding n+1 query situations involves hand optimizing a lot of stuff anyways. In my experience it's not really any less work than just aggregating stuff in a regular HTTP API, but it does seem to give a better developer experience on the frontend. At a certain scale, I think it could be worth the investment, but I don't think it really lives up to the hype.

> Especially since avoiding n+1 query situations involves hand optimizing a lot of stuff anyways. Rarely. Assuming the GraphQL server is using REST endpoints behind the scenes, i'm yet to find a request waterfall that required manual rather than automatic optimizations. I'm assuming there are cases where a manual path is faster, but they're less common that you'd think.

Not sure how magical your automatic optimizations are - but my experience does not at all mirror yours. i've certainly had to hand-optimize queries to improve performance, on top of the query already being automatically optimized. Removing unused data, tying across custom relations and moving things into different forms of caching are all quite manual efforts I've done plenty of. So, not sure how "less common than you'd think" holds up to scrutinization. I'm just one counterpoint.

Re: REST in Peace. Long Live GraphQL

#52

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

andreyf wrote: post #10

The reference implementation of GraphQL has a patent grant identical to React [1]. It does not seem wise to use anything with that rider if you have or would like to leave open the possibility of having patents which you license to / enforce against Facebook. The argument for patent disarmament strikes me as reasonable, but some companies have novel tech they would like to license to Facebook, and restricting the use…

Check this out https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revok...

might not be as bad as you think

Re: REST in Peace. Long Live GraphQL

#53

Post by supergeek133 » Mon, Jul 24, 2017, 5:17 PM UTC

I always enjoy these absolute "X tech is dead long live tech Y".

Note that earlier the top story on HN was about MSPaint and the top comment said:

> "All the comments that "you can just use X to do Y" is missing the point that Paint just works"

REST still (and will continue to) just work for most people, I'm sure some will switch or some will go straight to GraphQL, but lets not just go ahead and declare the whole thing dead. Haha.

Re: REST in Peace. Long Live GraphQL

#54

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

meesterdude wrote: post #51

andrewingram wrote: post #23

Earlier quoted context omitted.

> Especially since avoiding n+1 query situations involves hand optimizing a lot of stuff anyways. Rarely. Assuming the GraphQL server is using REST endpoints behind the scenes, i'm yet to find a request waterfall that required manual rather than automatic optimizations. I'm assuming there are cases where a manual path is faster, but they're less common that you'd think.

Not sure how magical your automatic optimizations are - but my experience does not at all mirror yours. i've certainly had to hand-optimize queries to improve performance, on top of the query already being automatically optimized. Removing unused data, tying across custom relations and moving things into different forms of caching are all quite manual efforts I've done plenty of. So, not sure how "less common than yo…

Mostly i'm referring to the methodology I followed here: https://dev-blog.apollodata.com/optimizing-your-graphql-requ...

I haven't looked into optimising other types of architecture (eg GraphQL server talking directly to the database), but there seem to be plenty of solutions that people are happy with.

Re: REST in Peace. Long Live GraphQL

#55

Post by aarohmankad » Mon, Jul 24, 2017, 5:21 PM UTC

theptip wrote: post #15

Anyone got experience transitioning a large production site from REST to GraphQL? I'm aware Yelp did this recently, wondering about any pain points. In particular, I have some FUD about how to go about rate limiting, when in theory a single request could grab every resource that the client is authorized to retrieve, and thrash the database. Looks like Github counts/restricts the number of total nodes returned: https:…

Also in response to protection against malicious requests, you may find the following link helpful.

It goes over several ways to secure your endpoints, along with pros and cons for each.

https://www.howtographql.com/advanced/4-security/

Re: REST in Peace. Long Live GraphQL

#56

Post by foota » Mon, Jul 24, 2017, 5:23 PM UTC

merb wrote: post #20

jrs95 wrote: post #8

Earlier quoted context omitted.

Especially since avoiding n+1 query situations involves hand optimizing a lot of stuff anyways. In my experience it's not really any less work than just aggregating stuff in a regular HTTP API, but it does seem to give a better developer experience on the frontend. At a certain scale, I think it could be worth the investment, but I don't think it really lives up to the hype.

well maybe on the frontend it looks good, but on the backend? meh parsing such a query is not painless. and maybe "simple" queries are looking good and simple, complex and bigger queries and big schema's are really really akward to implement.

Readily available packages in most languages can parse graphql queries for you.

Re: REST in Peace. Long Live GraphQL

#57

Post by vesak » Mon, Jul 24, 2017, 5:23 PM UTC

jrs95 wrote: post #11

ucho wrote: post #2

What is GraphQL? GraphQL is all about data communication Somehow it reminds me of good old "The S stands for Simple": http://harmful.cat-v.org/software/xml/soap/simple

Thank you for reminding me harmful.cat-v exists, this stuff is hilarious.

That place makes me feel like there's some hope in this industry.

Re: REST in Peace. Long Live GraphQL

#58

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

I've often wondered about this example: 1) Relational databases already had network interfaces 2) SQL isn't perfect, but it has been reliable for a long time 3) Why we didn't increase the performance and security of SQL interfaces, relational databases and just expose those to client applications, including in the browser, directly?

Ok, there are a lot of reasons.

I worked on a project once that was essentially a "data platform", kind of a SQL firewall to "any data" (a bit of a stretch, but that was the concept). You could put any data system (relational, non-relational, web services, etc.) behind it, but then join across heterogeneous systems using plain old SQL. You had a query language and a network interface, and since it was separate from the actual databases themselves, you could do some interesting things with security, caching and scalability in a different layer.

GraphQL has always seemed like the same kind of query abstraction over data, with a network interface. Props to Facebook for making the tech and releasing it open source.

This also makes me think about the command query responsibility separation (CQRS) pattern, a similar discussion.

EDIT: Also, lest we forget OData... which never really took off, but offers similar functionality.

Re: REST in Peace. Long Live GraphQL

#59

Post by tomc1985 » Mon, Jul 24, 2017, 5:25 PM UTC

  "who in their right mind would use XML over JSON today?"

Lost me already... there are lots of reasons to still use XML today. And since someone is going to ask, here are some:

* you want to use xpath

* you want to communicate with an enterprise app (salesforce, magento, etc)

* you need strongly-typed message-passing in a human-readable well-understood format (rules out messagepack, etc)

* nobody actually documented the API, but they might have a WSDL

Re: REST in Peace. Long Live GraphQL

#60

Post by davewritescode » Mon, Jul 24, 2017, 5:25 PM UTC

18nleung wrote: post #46

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

That's actually awesome, thanks for pointing that out!