GraphQL Introduction • Hacker News Board

Re: GraphQL Introduction

#41

Post by verbin217 » Sat, May 02, 2015, 11:04 AM UTC

underwater wrote: post #32

themgt wrote: post #29

Earlier quoted context omitted.

I think http/2 solves some of of the issues regarding round-trip. One real problem with mobile vs. web is versioning, the inability to ensure that you can keep your client & server in sync. In some ways one of the biggest advances I see from GraphQL/Relay is that should avoid most of versioning hell for mobile - there's effectively an agreed interop language for communicating data needs, and thus backwards compatibil…

HTTP/2 removes some of the overhead of requests, but there is still the problem of multiple round trips. For example, if you request your top three friends and their most recent post using REST you'll probably need to do four requests. And you can't parallelize them because you need to know your friends' IDs before you can construct the comment requests.

Actually this can be addressed with HTTP/2 although I think the solution may be just as complicated. If the yet-to-be-known parameters are encoded in the query string then the requests can be pushed to the client before the client knows it will be requesting them. This could be done with a middleware that used the Referer header (and maybe some fancy isomorphism) to determine what should be pushed.

Re: GraphQL Introduction

#42

Post by rapind » Sat, May 02, 2015, 12:35 PM UTC

nroman wrote: post #10

command_tab wrote: post #5

Earlier quoted context omitted.

I'm curious to learn how API response caching is affected by GraphQL. In a REST setup, there's a possibility that API responses can be cached. But if the response structure is dictated by the client, it seems like responses might differ and not be cacheable.

In practice it wouldn't make much sense to cache whole query responses to GraphQL queries because your hit rates would be too low due to the variability of the queries. You end up pushing a lot of the caching to the client. That's not really a big issue because if you're writing something like a Android or iOS app because you already need to be caching lots of data on the client-side to make the app responsive. On th…

Worth noting there's a massive performance penalty to pay when caching at the app level depending on your stack. On hardware where rails + memcached is struggling to handle 500 concurrents varnish or Nginx will easily handle tens of thousands.

Re: GraphQL Introduction

#43

Post by achr2 » Sat, May 02, 2015, 12:42 PM UTC

Since there is already a mix of predicates within the query (for sub objects) they should have unified the syntax. Something like:

user {

    id: 3500401,

    name,

    isViewerFriend,

    profilePicture  {

      size= 50,

      uri,

      width,

      height

    }

  }

As shown you could use a different indicator for filter properties that should not be included in the serialized object graph.

Re: GraphQL Introduction

#44

Post by mjburgess » Sat, May 02, 2015, 2:12 PM UTC

achr2 wrote: post #43

Since there is already a mix of predicates within the query (for sub objects) they should have unified the syntax. Something like: user { id: 3500401, name, isViewerFriend, profilePicture { size= 50, uri, width, height } } As shown you could use a different indicator for filter properties that should not be included in the serialized object graph.

Yeah, it's odd. It's not clear why they're just not using json... json will give you an homoiconic language of arbitrary descriptive power.

Re: GraphQL Introduction

#45

Post by underwater » Sat, May 02, 2015, 4:25 PM UTC

verbin217 wrote: post #41

underwater wrote: post #32

Earlier quoted context omitted.

HTTP/2 removes some of the overhead of requests, but there is still the problem of multiple round trips. For example, if you request your top three friends and their most recent post using REST you'll probably need to do four requests. And you can't parallelize them because you need to know your friends' IDs before you can construct the comment requests.

Actually this can be addressed with HTTP/2 although I think the solution may be just as complicated. If the yet-to-be-known parameters are encoded in the query string then the requests can be push ed to the client before the client knows it will be requesting them. This could be done with a middleware that used the Referer header (and maybe some fancy isomorphism) to determine what should be push ed.

True, but then you have the server duplicating logic from the client. This is very similar to the custom endpoint solution, which breaks down when you have multiple clients needing different data. You end up either under or over fetching.

Re: GraphQL Introduction

#46

Post by MasonOfWords » Sat, May 02, 2015, 6:22 PM UTC

steego wrote: post #11

nroman wrote: post #3

As an ex-Facebook employee, I can't wait for this to be released to the public. It is hard for me to overstate how much this infrastructure makes building products a joy, not to mention the tremendous developer and server efficiency that can be attained. I miss having the GraphQL stack so much when working on my own stuff. The client application should drive the decisions about what data to fetch. After all it's the…

As someone who's used OData for this sort of strong typed, ad-hoc interaction with the server, I'm really happy to see Facebook push this idea. Compared to OData, I really like how GraphGL's approach of making a query look like the data it's requesting.

I don't know, there are some tradeoffs there. Their sample appears to be "nearly JSON", which doesn't seem too helpful. Being close to but noncompliant with a standard doesn't bring anything but confusion.

And it isn't obvious what they're using for transport, but it seems like they aren't attempting to model programmatic resources as web resources the way that OData does. This is an okay decision if they're trying to make it transport-neutral (i.e. you can issue the same GraphQL request via Thrift or by HTTP POST), but in that direction lies the sins of SOAP.

In the past I've written a client-side caching layer for OData which was capable of doing the same automatic batching and partial cache fulfillment for hierarchical queries that they describe in the article. It is a good tool for writing complex client applications against generalized data services without giving up performance, and I'm not surprised that companies in our post-browser world are starting to move in that direction.

I'm a little bummed that Facebook is throwing its considerable weight behind yet another piece of NIH-ware, though. Beating up the REST strawman was a poor use of half of this article; I'd be much more interested to hear why we need GraphQL when there exists a standard like OData.

Re: GraphQL Introduction

#47

Post by MasonOfWords » Sat, May 02, 2015, 6:36 PM UTC

madewulf wrote: post #13

It really pleases me to finally see a big credible player tackling the REST orthodoxy. They state very well why REST APIs are not working well for mobile. Notably: "Fetching complicated object graphs require multiple round trips between the client and server to render single views. For mobile applications operating in variable network conditions, these multiple roundtrips are highly undesirable." Now, I'm wondering h…

In OData, these problems are solved by:

* Client communicate their desired projection and page size (via $select and $top query string parameters), which can then easily be mapped by the service into efficient calls to the underlying data store.

* OData client page sizes are polite requests, not demands. The server is free to apply its own paging limits, which are then communicated back to the client along with the total results count and a URL that can be followed to get the next page of results. Clients are required to accept and process the page of entities they are given, even if that number differs from the count which was requested due to server limits.

I'd assume GraphQL will adopt similar functionality, if it hasn't already.

Re: GraphQL Introduction

#48

Post by verbin217 » Sat, May 02, 2015, 11:13 PM UTC

underwater wrote: post #45

verbin217 wrote: post #41

Earlier quoted context omitted.

Actually this can be addressed with HTTP/2 although I think the solution may be just as complicated. If the yet-to-be-known parameters are encoded in the query string then the requests can be push ed to the client before the client knows it will be requesting them. This could be done with a middleware that used the Referer header (and maybe some fancy isomorphism) to determine what should be push ed.

True, but then you have the server duplicating logic from the client. This is very similar to the custom endpoint solution, which breaks down when you have multiple clients needing different data. You end up either under or over fetching.

To prevent the over/under fetching you're describing you could partition your endpoints and make multiple requests. Although, thats definitely a code-maintenance win for GraphQL.

It seems like if you were co-executing the client on the server you could trivially achieve perfect fetching. GraphQL may actually over fetch in many situations. Here's an example: the client fetches a list of objects, filters it, and then fetches more data referenced by the results. With GraphQL, if you don't automagically parse the filter out of the client code, you over-fetch. However, the HTTP/2 solution could just push the 2nd fetch as it was made by the co-executed client.

All that being said, GraphQL certainly alleviates the server-side load co-execution would imply and that's likely more suitable to the scale Facebook operates at.

Re: GraphQL Introduction

#49

Post by underwater » Sun, May 03, 2015, 2:57 AM UTC

verbin217 wrote: post #48

underwater wrote: post #45

Earlier quoted context omitted.

True, but then you have the server duplicating logic from the client. This is very similar to the custom endpoint solution, which breaks down when you have multiple clients needing different data. You end up either under or over fetching.

To prevent the over/under fetching you're describing you could partition your endpoints and make multiple requests. Although, thats definitely a code-maintenance win for GraphQL. It seems like if you were co-executing the client on the server you could trivially achieve perfect fetching. GraphQL may actually over fetch in many situations. Here's an example: the client fetches a list of objects, filters it, and then f…

Yes, that's a tricky problem. Generally GraphQL solves it by filtering on the server. You'd request something like `friends(age: 25, order: dob, first: 10) { name, profilePicture }` and pass that straight through to the UI.

There are some situations where this doesn't work to well. For search suggestions, for example, you might not want to request `searchSuggestion(query: "Tom Smi") { }` on every keystroke because sequential queries will have a lot of duplication. In this case we can just fetch the IDs of the results and do a separate query to fetch the data for the people that we don't know about yet.

Having the server know about client queries (and therefore preemptively running queries) is something we specifically avoided with GraphQL. If the server knows what the client wants then sending any query across the wire doesn't make sense at all. It also falls down if data requirements client changes across client versions. You quickly end up in a place where the server has to know about all possible client queries, which is complex difficult to maintain.

Re: GraphQL Introduction

#50

Post by leebyron » Mon, May 04, 2015, 12:37 AM UTC

mosselman wrote: post #37

ChrisGaudreau wrote: post #22

Earlier quoted context omitted.

http://facebook.github.io/react/blog/2015/02/20/introducing-...

I read that already :) thanks. The question I have is rather whether Relay is an alternative to Flux or that the two are meant to be used in conjunction. Also, which usecases would make Flux better and which Relay (if they are not to be used together).

Relay is one specific implementation of the Flux pattern.

Flux is a generalized pattern and there are a number of libraries out there which implement their own flavor of Flux. Relay is one of those libraries implementing the Flux pattern which focuses on describing data dependencies in the same place the data is used.