Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GraphQL Introduction

facebook.github.io

Post reply on HN
Print view View original

11–20 of 53 posts

Re: GraphQL Introduction

#11

Post by steego »

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.

Re: GraphQL Introduction

#12

Post by donw »

This looks seriously useful, but I'm having a hard time seeing how something like Relay will play ball with, say, vector clocks, or client-side undo, as it sounds fairly welded to the Component.

Maybe the idea is to do that all on the server? Or in the Store? Very curious to see the implementation.

Re: GraphQL Introduction

#13

Post by madewulf »

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 how they manage to make the computation of the responses on the server side no too expensive. It seems clear that there is a risk in such a system to define queries that pull way too more data at once. Also, the question of pagination comes to mind. How can you handle that efficiently?

Re: GraphQL Introduction

#14

Post by wehadfun »

1. How much more complicated does this make the server? Seems like some pretty fancy code would have to be written to turn GraphQL tot SQL.

2. I think the biggest issue with HTTP verbs is that there is not an flexible way for the client to control the data that comes back from server. GETs dont have a body and the other verbs are for add/mod of data. I'm assuming that they are using POST for everything.

Re: GraphQL Introduction

#15

Post by vosper »

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…

It seems to me that GraphQL could be awesome when you exclusively control the back-end and the front-end, but do you think it will work as well if you're building an API that also needs to support third-party clients? Would REST still be better in that scenario?

Edit: I see that they partially address this: "Many of these attributes are linked to the fact that “REST is intended for long-lived network-based applications that span multiple organizations” according to its inventor. This is not a requirement for APIs that serve a client app built within the same organization."

Re: GraphQL Introduction

#16

Post by schrockn »

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…

Re: the risk of overfetching, this is certainly a risk. Like any tool, it can be misused. One of the motivations of Relay is in fact this very issue. By coupling the data-fetching with the view more tightly, we can more accurately track and fix overfetching earlier in the development cycle.

In terms of being not too expensive, an important attribute of the system is that the server publishes capabilities that clients selectively use. For example, we explicitly do not allow clients to send up arbitrary strings for filtering and query predicates and what not; servers have to explicitly expose those via arguments to fields. eventMembers(isViewerFriend: true) { ... } or similar formulations that are encoded in the type system. This prevents people from ordering inefficiently (e.g. large data sets without indexes).

Re: pagination. This is absolutely a core pattern that we are excited to talk about as we explain the system more. Broadly we handle pagination through call arguments, e.g. friends(after: $someCursor, first: 10) { ... } There's a lot of subtlety there which I won't go into until we dive into that topic deeply.

Re: GraphQL Introduction

#17

Post by roskilli »

kolev wrote: post #2

What are the alternatives to using something similar to GraphQL and Relay now? I've found Transmit [0], but what are the other alternatives? Has someone tried to integrate BreezeJS [1]? Also, any news about the upcoming Falcor [2]? [0] https://github.com/RickWong/react-transmit [1] http://www.getbreezenow.com/ [2] https://www.youtube.com/watch?v=WiO1f6h15c8 P.S. Also, GraphNoQL [3] came out quickly after the announce…

If you only care about iOS and a layer on the backend that can sit between your actual app server and the client you could consider Jetstream:

https://github.com/uber/jetstream

https://github.com/uber/jetstream-ios

It's a considerably different model however. More about realtime updates.

Re: GraphQL Introduction

#18

Post by madewulf »

schrockn wrote: post #16
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…

Re: the risk of overfetching, this is certainly a risk. Like any tool, it can be misused. One of the motivations of Relay is in fact this very issue. By coupling the data-fetching with the view more tightly, we can more accurately track and fix overfetching earlier in the development cycle. In terms of being not too expensive, an important attribute of the system is that the server publishes capabilities that clients…

Thanks a lot for these insights. I'm definitely looking forward to discover more about all this.

Re: GraphQL Introduction

#20

Post by schrockn »

vosper wrote: post #15
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…

It seems to me that GraphQL could be awesome when you exclusively control the back-end and the front-end, but do you think it will work as well if you're building an API that also needs to support third-party clients? Would REST still be better in that scenario? Edit: I see that they partially address this: "Many of these attributes are linked to the fact that “REST is intended for long-lived network-based applicatio…

That's a great point. We definitely have designed it for first party clients in mind. This doesn't preclude use cases in the future, but for the short term, this is a nongoal.
Post reply on HN