Add GraphQL support #125

Open
chrisabrams opened this Issue Feb 19, 2016 · 45 comments

Projects

None yet
@chrisabrams
Contributor

I don't see it anywhere - is this an adaptor in another repo? GraphQL is definitely one piece of the project I am excited to use.

@mglukhovsky
Member

@chrisabrams: we're working through details on how to add a GraphQL adapter offline -- so far we've started with a rich API to query the backend, but GraphQL is on the list.

This issue is a good opportunity to discuss proposals and define what a GraphQL adapter would look like.

@taion
taion commented Feb 19, 2016

Worth keeping an eye on facebook/relay#541, since Relay doesn't actually have subscription support yet.

@danielmewes
Member

It's worth noting that GraphQL is not at the core of Horizon. It can (and very likely will) be an additional protocol that can use Horizon functionality and infrastructure. rethinkdb/rethinkdb#3711 (comment) is a good summary of why Horizon is different from GraphQL

@deontologician deontologician added this to the Subsequent milestone Feb 20, 2016
@coffeemug coffeemug changed the title from Where is GraphQL? to GraphQL support Mar 1, 2016
@coffeemug coffeemug changed the title from GraphQL support to Add GraphQL support Mar 1, 2016
@coffeemug
Member

I renamed the issue to "Add GraphQL support" (sorry, e-mail users!)

GraphQL will not make it into v1, but I'm hoping we can add a GraphQL adapter on top of the protocol quickly after launch. If anyone has proposals for what specifically you're looking for wrt GraphQL, please post it here. I think the general goal should be to have a complete backend out of the box, so users could build React/Relay apps without initially writing any backend code. Once the app gets sophisticated, GraphQL should work similarly to the basic protocol -- it should be possible to import Horizon into Node as a library, and add custom handlers to do advanced operations.

I don't have details on how GraphQL will work yet; once the first version of Horizon ships, I expect we'll get to this pretty quickly.

@alexgorbatchev

complete backend out of the box, so users could build React/Relay apps without initially writing any backend code

That! I think it would be a good idea to have GraphQL support during the initial public announcement, I believe it would make a bigger splash that way.

@coffeemug
Member

Adding GraphQL for the initial launch would be incredible, but unfortunately we don't have the resources to make it happen. If someone wants to contribute, it would be a really fun project to work on (wink wink!)

@taion
taion commented Apr 2, 2016

To reiterate, I don't think it's a question of resourcing. It's just about impossible right now because the semantics defined for subscriptions in GraphQL are restricted to just having a support for a subscription message type.

I think you're fundamentally blocked on facebook/relay#541 here, because until that lands, there are no real semantics for e.g. subscription updates. You have a way to establish subscriptions, but nothing for subscription updates, and no semantics (or client-side support) for consuming such updates.

@coffeemug
Member

I don't think that's quite right. We could add GraphQL support without subscriptions (i.e. support fetch semantics but not watch semantics). It wouldn't give users the realtime features of horizon, but that's ok -- once GraphQL facebook/relay#541 we can add watch semantics pretty easily.

@taion
taion commented Apr 4, 2016

Ah, I see. I take that back, then. Thanks.

@tslocke
tslocke commented Apr 15, 2016

If anyone has proposals for what specifically you're looking for wrt GraphQL, please post it here

I realise this is stating the obvious, but maybe it doesn't hurt to sanity check that people are on the same page...

Composable UI components!

I want to build my UI as a collection of components, each annotated with the data needs of that one component (in GraphQL) and have the framework figure out the composite query that gets sent to the server.

I want my dev process to look like:

  1. Write components
  2. Tell Horizon which one is the root component
  3. hzops deploy : )

OK there may be a few steps missing in there, but I think keeping this ideal in mind will give a good direction for the design of the GraphQL adapter.

The weird thing in all this is that Relay currently has a crazy high level of boilerplate. As we saw with Meteor, I think Horizon needs a message like "look how little code is required to do amazing things!", so excessive boilerplate is a problem.

So far, Horizon wants to stay out of the view layer, but the real promise of GraphQL is fundamentally about moving data access into UI components. Very interested to hear thoughts on this.

Maybe the hard part is finding the right boundary for where Horizon ends and Relay begins.

@teslan
teslan commented Apr 15, 2016 edited

Please keep in mind that I am your Web 0.2 guy (someone who is 55+ and who went from punched cards to IBM3270 terminals and only 2-3 years ago, in a passive way got introduced to Web, the IDBM3270 pig with lipstick, etc, etc) However, ...

The environment that I am already dreaming of is something that has CouchDB's replication, RethinkDB's push, Solr/Elastic's search and PouchDB's in the browser storage and localization. With that, one would have a complete circle, where data would be trickling down from source(s) to the consumer(s) and back. From what I can tell, RethinkDB is doing its pushing in some magical but most efficient way that is from deep inside or at least from within the DB itself (not from logs as in Mongo/Meteor). That is what for me comes across as RethinkDB's niche and enabling technology. Horizon, on the other hand, got my attention mostly because it sugar coats all of the complexities that with lots of blood, sweat and tears that even I could code [by age 65+]. Similarly, I could code the client end [by age 75+]. However, with some sugar coating on the client end, RethinkDB could/would end up, in a non too prescriptive way, doing what Meteor tried and failed to do and mostly because it did not have "sugar coated" pieces that got one going faster, but pieces that could easily be replaced - instead of offering Meteor's all or nothing proposition.

Would it be better in some other topic to plead for this sugar coating on the client end?

@cmnstmntmn

i was seeing this https://github.com/matthewmueller/graph.ql
describe itself as a "Faster and simpler technique for creating and querying GraphQL schemas"

@tslocke
tslocke commented May 4, 2016

Would love to see some engagement from the Rethink team on this issue. I understand GraphQL is fundamental to the Horizon project, but it's not at all obvious what that means. Many in the wider community are pointing out that GraphQL is not a query language at all, but more of an "extensible graph based API protocol". But if there's no backend, that interpretation doesn't make sense. Further (per my previous comment), GraphQL grew out of a desire for a more "plug and play" compositional front-end, but Horizon wants to stay out of the view layer.

So... lots of questions. The scope of Horizon is very broad so I'm sure it's just that the core folks are busy on other pieces.

@jeveloper

Have you guys looked into Apollo stack?
Seems like Meteor wants to revamp their stack altogether and build it with graphQL right away

@coffeemug
Member

So far there hasn't been much engagement on this issue because we have our hands full building out all the other components. The challenge here is mental bandwidth -- it's hard to think through fifty things at once, and GraphQL adds a significant layer of complexity that would slow down horizon development if we kept it in mind now. So the idea is to build out v1, and then switch gears and add a GraphQL adapter.

It's true that GraphQL isn't a query language, but an API protocol (the easiest way to think of it is as a replacement for REST). The Horizon protocol is somewhat orthogonal to GraphQL, so it should be fairly easy enough to build a GraphQL adapter on top of that. Once v1 ships (which is going to be real-soon-now[tm]) we'll be able to be much more active on this issue. If I had to take a guess, I think we'll ship a GraphQL adapter for Horizon around July, which means there will be a lot more discussion on it here starting late May or early June.

@stubailo

We have some early experiments with integrating data streams into Apollo Client, so if anyone wants to have an in-depth conversation I'm always available!

@abastardi abastardi referenced this issue in mattkrick/meatier May 23, 2016
Open

Thoughts on Horizon? #152

@abastardi

@coffeemug, regarding subscriptions via GraphQL, you mentioned, "once GraphQL facebook/relay#541 we can add watch semantics pretty easily."

But according to facebook/relay#541 (comment), it doesn't look like Relay is planning to support subscriptions in open source at all. Assuming this is the case, will Horizon still aim to support subscriptions via its GraphQL layer?

@Poincare Poincare referenced this issue in apollostack/apollo-client May 31, 2016
Closed

using apollo with rethinkdb horizon #257

@gregbenner
Contributor
gregbenner commented May 31, 2016 edited

Might be worth chatting with the strapi team or having a look, they did some work on a waterline adapter for graphQL that works well. https://github.com/wistityhq/waterline-graphql Not sure if it helps though.

@benjaminjs

If GraphGL isn't adding the support for real-time subscriptions. It looks like Falcor is looking at doing so. Netflix/falcor#425

@dortzur
dortzur commented Jun 15, 2016

@coffeemug It's mid June. any updates :) ?

@deontologician
Contributor

@dortzur We are working on a plugin system that will allow us to do this cleanly, check out #588

@dortzur
dortzur commented Jun 15, 2016

Awesome! looking forward to it

On Wed, Jun 15, 2016, 18:58 Josh Kuhn notifications@github.com wrote:

@dortzur https://github.com/dortzur We are working on a plugin system
that will allow us to do this cleanly, check out #588
#588


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#125 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAZoI1Um5hzbQHKLtSvfasORk0W0loRbks5qMCE5gaJpZM4HeCEo
.

@NathHorrigan

What's the expected timeframe for GraphQL support or is it to early to say?

@deontologician
Contributor

@NathHorrigan I don't know a timeline, but the dependency tree goes:

  1. Implement plugin system
  2. Implement GraphQL plugin (making GraphQL possible)
  3. Implement tooling to make it easy create and modify GraphQL mappings

The graphQL plugin is probably not going to be a huge deal, mostly serialization and defining a configuration language to map graphQL queries to reql queries.

Point 3 above requires some explanation. We'd toyed with the idea of mapping queries directly to horizon collections, but this is probably not flexible enough for most people. In addition, there are questions around what indexes to build, and how to do more advanced queries. So the result will likely be heavy on config. Because of that we want to see what patterns emerge and where we can make configuring it less painful. It'll probably end up being part of the webui

@abastardi
abastardi commented Jun 16, 2016 edited

Note, Facebook is now experimenting with real-time update support in GraphQL via the @live directive: https://youtu.be/ViXL0YQnioU?t=15m32s

@sdwlig
sdwlig commented Jul 21, 2016

The Falcor model ( https://netflix.github.io/falcor/ ), the main competitor to GraphQL, is very nice also. The your data is your API model is appealing on a number of levels. In several ways, it is easier and cleaner.

@sjmcdowall

Has anyone looked at Apollo from the Meteor guys? That's fairly compelling too (at least it looks like it will be!) :) Apollo Stack

@stubailo

I think Apollo Client will be a great way to get GraphQL data into your UI when the Horizon server/RethinkDB start supporting it! It will be great if all of these client/server implementations can work together, so you don't have to be bound to just one full-stack solution, but can pick from several compatible options.

@tonyxiao
tonyxiao commented Sep 8, 2016

One big idea in GraphQL is presenting a single, unified API to the client even though under the hood it might be drawing data from many different sources. Will horizon support that? It almost seems that as application scale you'd want to write your own graphQL server that resolves some queries against RethinkDB and other queries against other data sources (SQL, external API, etc.)

@tonyxiao
tonyxiao commented Sep 8, 2016

@chrisabrams what's the best way for someone to get started using GraphQL with rethinkdb who needs real time support? Any workarounds until an official solution is available?

@chrisabrams
Contributor

@tonyxiao if you want realtime support wouldn't you want websockets?

@tonyxiao
tonyxiao commented Sep 8, 2016

Possibly yea. Question is how to work with rethink db in this case.

@Xample
Xample commented Sep 12, 2016 edited

Any information on how a GraphQL server is supposed to broadcast its changes to the client ? AFAIK currently FB has kept this feature private. However, if there is several GraphQL servers / clients which should be cross compatible, there must be a community-driven solution for those push notifications. What is the current status ?
[edit] just found apollostack/graphql-server#34 which could be related

@danielmewes
Member

@Xample That is indeed one of the open questions. We haven't settled on anything there yet.

@stubailo

We just shipped an initial version of GraphQL subscriptions, it works with any JavaScript backend for frontend: https://medium.com/apollo-stack/graphql-subscriptions-in-apollo-client-9a2457f015fb#.t92z7dsb3

Here's a work in progress package to wire up to Redis: https://github.com/davidyaha/graphql-redis-subscriptions

It would be cool to have something like that for RethinkDB as well!

@Xample
Xample commented Sep 13, 2016

@stubailo I just saw it this morning, excellent! Yes definitely a RethinkDB based example supporting subscriptions would be awesome.

@cometta
cometta commented Sep 13, 2016

you mind want to have a look at https://github.com/mattkrick/cashay , similar like Apollo but with more features. Yes, it has subscriptions as well.

@jeveloper

Hey folks, i thought RethinkDB team mentioned that GraphQL was meant to go into 2.0 version which shipped.
Is there anything in 2.0 that can do graphql?

thanks

@deontologician
Contributor

No graphql yet, though it is not forgotten. We need to get some
foundational work in first (plugins)

On Tue, Sep 13, 2016, 07:36 Serge Bornow notifications@github.com wrote:

Hey folks, i thought RethinkDB team mentioned that GraphQL was meant to go
into 2.0 version which shipped.
Is there anything in 2.0 that can do graphql?

thanks


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#125 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAFVpvyyJ7Jkz6gHdlmXfPogu_Jm36aks5qprTNgaJpZM4HeCEo
.

@corysimmons

What's the status of RethinkDB + Horizon now that the company side sank?

If this isn't going to be added anytime soon, can a contrib remove this:

image

@marshall007
Contributor

@corysimmons the former RethinkDB engineers are still settling in at Stripe. @Tryneus just got back from vacation and is still working on the new plugin system for the 3.0 release. It involves a lot of cross-cutting changes, so it's kind of a blocker on most other things. Once we get that release pushed through you can expect more active development and it will be much easier for contributors to get involved and/or develop third-party plugins.

@corysimmons
corysimmons commented Nov 10, 2016 edited

Awesome. I have some cool/secret ideas for this db. :O

Glad it ain't dead.

@jeveloper

Thanks @marshall007 !

@shahabio

👍

@j209
j209 commented Dec 6, 2016

Any news?!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment