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

21–30 of 53 posts

Re: GraphQL Introduction

#21

Post by schrockn »

wehadfun wrote: post #14

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.

It is absolutely not that simple on the server, but we hope do to a lot of the heavy lifting for you via our open source release of code and spec in terms of lexing, parsing, and executing a query.

Re: GraphQL Introduction

#24

Post by kolev »

roskilli wrote: post #17
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.

Thanks! I'm definitely gonna look into it!

Re: GraphQL Introduction

#25

Post by kolev »

mandeepj wrote: post #9

If you can't use GraphQL due to some reason then there is an alternate - http://www.getbreezenow.com/breezejs

Well, we have to wait a few months for GraphQL to get open-sourced, but, anyway, I find BreezeJS better personally as defining GraphQL in strings is more old-school than using promises or generators.

Re: GraphQL Introduction

#26

Post by bsimpson »

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…

I'm also excited to see Jafar Husain's Falcor:

https://www.youtube.com/watch?v=hOE6nVVr14c

It's a different implementation of the same concept.

Re: GraphQL Introduction

#28

Post by rektide »

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…

I like how JSON-LD lets one embed many resources inside a document. And there are plenty of good preludes to this recent emergence: Soundcloud wrote about how they used an instance store 3 years ago in their clientside to extract all relevant models, and push them into an "instance store" where anyone else might find the data when they need it. https://developers.soundcloud.com/blog/building-the-next-sou...

What's really exciting is an expressive model that allows code to state what dependencies it has. The transport and fulfillment of needed data- what intermediary stores the data gets to and how pending views are signaled availability- is a more mechanistic, rote, already faced task, albeit one that each company seems to tackle on their own. The step further- declaring and modeling dependencies, is what makes GraphQL an interesting capabilities.

Soundcloud's 3 year old blog post is a good reference to show that "instance stores"- these clientside object database services- have been around for a good while, and can be done fine with REST as easily as without.

Re: GraphQL Introduction

#29

Post by themgt »

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…

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 compatibility during API evolution should be far less complicated.

Post reply on HN