Add GraphQL support

[chrisabrams]

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]

@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]

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

[danielmewes]

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

[coffeemug]

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]

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]

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]

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]

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

[tslocke]

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.

[ghost]

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]

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]

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]

@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?

[gregpalaci]

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.

[lazyeasydev]

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

[dortzur]

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

[deontologician]

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

[dortzur]

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]

@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]

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

[sdwlig]

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]

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]

@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]

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

[tonyxiao]

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

[Xample]

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 apollographql/apollo-server#34 which could be related

[danielmewes]

@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]

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

[cometta]

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]

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:

[marshall007]

@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]

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

Glad it ain't dead.

[jeveloper]

Thanks @marshall007 !

[shahabio]

👍

[j209]

Any news?!

[sp90]

@marshall007 @Tryneus what is the status on all of this - seems like its dead which i personally thinks is sad :(

[corysimmons]

Rethink lives on, but this project seems dead guys...

[rnenjoy]

I personally think horizon can die as long as rethinkdb lives on. What would benefit the whole realtime community was if someone could write an awesome plugin for apollo graphql server that would make graphql subscriptions easy peasy thanks to rethinkdb changefeeds.

[Urigo]

@DxCx

[rnenjoy]

What do you guys think of this?

apollographql/graphql-subscriptions#93

[winuxue]

Any update?

[sjmcdowall]

Isn’t Horizon rather a dead project ??

…

On Jul 28, 2017, at 12:45 PM, winuxue ***@***.***> wrote: Any update? — 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/AB8M7c1ovTzHWMIq300ek2jlbqivV1G5ks5sShBBgaJpZM4HeCEo>.