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

GraphQL Working Draft

facebook.github.io

Post reply on HN
Print view View original

41–50 of 71 posts

Re: GraphQL Working Draft

#41

Post by TheCoelacanth »

applecore wrote: post #18
stevepike wrote: post #15

Earlier quoted context omitted.

The trickiness will come in handling authentication for all the nested resources (e.g., user X can only see public photos for user Y, and can't update them) and generating efficient queries to a relational datastore. Coming up with a clean architecture for that actually seems like a fun project!

It's a good thing that relational databases solved the problem of generating efficient execution plans for ad-hoc queries about thirty years ago—with SQL.

Yeah, but the stupid users insist on clicking buttons and stuff instead of typing in SQL.

Re: GraphQL Working Draft

#42

Post by _cbsz »

vjeux wrote: post #8

Lee Byron is talking about it at React Europe right now, here's the live stream (which supports play back): https://www.youtube.com/watch?v=UclvvqNtNNo

That link says "This video is private".

Re: GraphQL Working Draft

#43

Post by mfenniak »

jaegerpicker wrote: post #26
dschafer wrote: post #23

Earlier quoted context omitted.

GraphQL doesn't prescribe a particular approach to mutations; it allows the server developer to specify what mutations are available. For example, at Facebook we have a storyCreate mutation, and a friendRequestAdd mutation. Mutations are just top level fields, but with side effects; because they are fields, the client sends up a selection set with the mutation. This allows the client to receive whatever data it needs…

Awesome, thanks for the explanation. My team is rolling out an REST API currently and I've always wanted a Linq/SQL type of interface to REST API's. I could definitely see GraphQL evolving in that kind of direction. Some amazingly cool open source tech coming out of Facebook these days.

I'd suggest that you be wary of going down the route of making your API too flexible. It becomes very difficult to scale up a service that provides flexibility.

Imagine a simple case where you're storing hundreds of records of users, and providing the flexibility to order by any field on the user, and of course, you're paginating those results. Now, scale up; you're storing tens of millions of those same record... how do you quickly retrieve the first ten records ordered by their e-mail address field? Same thing, ordered by their last name. Same thing, ordered by their country. Did you just create database indexes to support each of those use cases? Ugh.

In my opinion, a REST API (well, any API) should be limited to supporting only the business use-cases it is designed to implement. I wouldn't want to build a "Linq/SQL" type of interface, because then I have to support all the weird queries people will come up, and still meet my requirements to scale over time. Don't provide this kind of flexibility unless the value it gives your product is absolutely incredible, because, the headaches it provides could be equally incredible.

Re: GraphQL Working Draft

#44

Post by applecore »

TheCoelacanth wrote: post #41
applecore wrote: post #18

Earlier quoted context omitted.

It's a good thing that relational databases solved the problem of generating efficient execution plans for ad-hoc queries about thirty years ago—with SQL.

Yeah, but the stupid users insist on clicking buttons and stuff instead of typing in SQL.

The point is that relational databases will serve as the data model for most GraphQL application servers. Obviously, end-users don't have to write their own queries.

Re: GraphQL Working Draft

#45

Post by darknoon »

Murkin wrote: post #10

There was a comment on the original blog post that while they (Facebook) use GraphQL they still fall back to Flux for some of the data handling. Was this solved ? Did they manage to handle all the data needs of their apps with GraphQL or is it still limited to certain areas ?

I think you mean falling back to "FQL," the old SQL-like syntax, since Flux is more of a client architecture thing (paired with GraphQL).

FQL has some holdouts in legacy code, but the vast majority of the iOS app is using GraphQL. There are a bunch of tools built around using it, and it's the "right way" these days. Maybe a year or more ago ago, the notifications tab was using FQL. It makes sense to convert things since the risk in switching is outweighed by a reduction in server CPU, network bytes transferred, and ability of tools to understand the code. When we built Paper, we did notifications on GraphQL because there wasn't the risk of breaking something.

You can almost certainly handle all of your 'data needs' with GraphQL... :D

Re: GraphQL Working Draft

#46

Post by darknoon »

applecore wrote: post #18
stevepike wrote: post #15

Earlier quoted context omitted.

The trickiness will come in handling authentication for all the nested resources (e.g., user X can only see public photos for user Y, and can't update them) and generating efficient queries to a relational datastore. Coming up with a clean architecture for that actually seems like a fun project!

It's a good thing that relational databases solved the problem of generating efficient execution plans for ad-hoc queries about thirty years ago—with SQL.

Also, keep in mind that most big websites aren't just a single box you can query. A plan for fetching data across >>1000s of boxes works a bit differently than within MySQL or whatever.

Usually you end up making layers of abstraction / cacheing / parallelization atop them that don't have an easy SQL interface for the frontend to query. FQL was heavily sanitized and abstracted anyway, not directly SQL onto the boxes--imagine that security shitshow!

Re: GraphQL Working Draft

#47

Post by woah »

darknoon wrote: post #45
Murkin wrote: post #10

There was a comment on the original blog post that while they (Facebook) use GraphQL they still fall back to Flux for some of the data handling. Was this solved ? Did they manage to handle all the data needs of their apps with GraphQL or is it still limited to certain areas ?

I think you mean falling back to "FQL," the old SQL-like syntax, since Flux is more of a client architecture thing (paired with GraphQL). FQL has some holdouts in legacy code, but the vast majority of the iOS app is using GraphQL. There are a bunch of tools built around using it, and it's the "right way" these days. Maybe a year or more ago ago, the notifications tab was using FQL. It makes sense to convert things si…

I think the OP meant Flux. I also read about it being used to store things that are not being persisted.

Re: GraphQL Working Draft

#48

Post by RussianCow »

mfenniak wrote: post #43
jaegerpicker wrote: post #26

Earlier quoted context omitted.

Awesome, thanks for the explanation. My team is rolling out an REST API currently and I've always wanted a Linq/SQL type of interface to REST API's. I could definitely see GraphQL evolving in that kind of direction. Some amazingly cool open source tech coming out of Facebook these days.

I'd suggest that you be wary of going down the route of making your API too flexible. It becomes very difficult to scale up a service that provides flexibility. Imagine a simple case where you're storing hundreds of records of users, and providing the flexibility to order by any field on the user, and of course, you're paginating those results. Now, scale up; you're storing tens of millions of those same record... ho…

> Imagine a simple case where you're storing hundreds of records of users, and providing the flexibility to order by any field on the user...

You don't have to allow ordering by any field. You can define a list of fields that you can order by, and only allow those. I don't see the problem with doing that. But if you must allow ordering by any field...

> Did you just create database indexes to support each of those use cases? Ugh.

...then yes, you would need to do that.

I think the cool thing about GraphQL (at least from my understanding) is it doesn't necessarily give you full power to query data in any arbitrary way from the client--it just provides a more flexible interface for defining what data you want returned from the API and how you want that data structured. It doesn't necessarily have to be a 1:1 mapping of your DB schema, and in most cases I don't think it should be.

Re: GraphQL Working Draft

#49

Post by barakm »

I've been looking forward to this! One question; it appears as though the types and schema are passed with every request (eg https://github.com/graphql/graphql-js/blob/master/src/graphq... ) -- I assume part of the reason for this is versioning/sharing the schema, but is it always external, does the server ever know the schema a priori -- what's the thinking around this design decision?

(It's a plausible idea! I'm just curious on the what and why)

Re: GraphQL Working Draft

#50

Post by jessep »

jaegerpicker wrote: post #19

So, I haven't had enough time to really dig into the spec but it doesn't seem like the language has any kind of insert or update type of feature. Perhaps I just missed it though. But if it doesn't it seems like you would need a pretty large dataset to make this worth it, right? I mean for any kind of a change event you still need to support a standard REST API, as this really only replaces the GET operation. Am I mis…

Just fyi, the doc mentions mutations here: http://facebook.github.io/graphql/#sec-Language.Operations
Post reply on HN