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

31–40 of 53 posts

Re: GraphQL Introduction

#31

Post by gobengo »

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 has recently become popular to be anti-REST. It makes you seem smart and more knowledgable than average.

In practice, I think that an GraphQL API is still a form of REST.

People hate on REST when they should be hating on the bad instances of things that others made and said 'But it's REST!', regardless of whether it was or wasn't or that person had RTFM https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding...

Re: GraphQL Introduction

#32

Post by underwater »

themgt wrote: post #29
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 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.

Re: GraphQL Introduction

#33

Post by kolev »

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…

Forgot to add the following: JayData [0], engen [1], and Astarisx [2]?

[0] http://jaydata.org/

[1] https://github.com/storehouse/engen

[2] https://entrendipity.github.io/astarisx/

Re: GraphQL Introduction

#34

Post by framp »

I don't see why using something like GraphQL should push REST out of the way. I want to create and manage my resources, publish them on the web via a RESTful API - and also provide a way for the user to query those resources in a meaningful way with just one call. That's exactly what I'm doing today - but with a proprietary language (and querystring - which is not ideal).

I see this as the perfect companion for REST and I hope it will be standardized. Kudos

Re: GraphQL Introduction

#35

Post by spicyj »

gobengo wrote: post #31
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 has recently become popular to be anti-REST. It makes you seem smart and more knowledgable than average. In practice, I think that an GraphQL API is still a form of REST. People hate on REST when they should be hating on the bad instances of things that others made and said 'But it's REST!', regardless of whether it was or wasn't or that person had RTFM https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding.…

The post specifically calls out that distinction:

> We are interested in the typical attributes of systems that self-identify as REST, rather than systems which are formally REST.

Re: GraphQL Introduction

#36

Post by iLoch »

schrockn wrote: post #21
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.

Can you comment on whether or not you'll be releasing any implementations and if so, what languages they'll be in?

Re: GraphQL Introduction

#37

Post by mosselman »

ChrisGaudreau wrote: post #22
mosselman wrote: post #19

So is Relay an alternative to Flux or how are the two related?

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).

Re: GraphQL Introduction

#39

Post by frnktrn »

People often talk in terms of there being only two layers of a webstack: The client/webapp layer and the server layer. I think what Netflix did (explained http://techblog.netflix.com/2012/07/embracing-differences-in...) is really the way to go.

It would be nice having custom adapter endpoints for your clients and devices that in turn fans out multiple calls on the backend border (if you are using a service based backend architecture), while still having the option of going directly to the service endpoints for third party integrations and what not. Having this adapter layer based on GraphQL would be neat, assuming one could break down GraphQL queries to individual REST based endpoint calls.

Re: GraphQL Introduction

#40

Post by WimLeers »

iLoch wrote: post #36
schrockn wrote: post #21

Earlier quoted context omitted.

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.

Can you comment on whether or not you'll be releasing any implementations and if so, what languages they'll be in?

+1, knowing the languages of the open sourced implementations would be very helpful.
Post reply on HN