
Reactive GraphQL - johanbrook
http://info.meteor.com/blog/reactive-graphql
======
bwhitty
Meteor is about the UX.

The ease of getting up and running, the ease of tools, and the ease of
deployment. On no React stack can you (and in the future this will be more
simple) run

    
    
      meteor create my-react-project
      npm init && npm install react
    

And start coding JSX, ES2015/2016 immediately. There is a non-trivial amount
of boilerplate and configuration you need to do to get this working my hand,
and while it can provide a greater level of control, it undoubtedly adds to
the overall weight of code you need to maintain.

Then hypothetically after some time of development, do

    
    
      meteor add-platform ios
      meteor add-platform android
      meteor add-platform desktop (this is theoretical currently, but there exist packages which do exactly this)
    

And have Cordova iOS and Android builds, and an Electron desktop app. Then in
a few weeks, do

    
    
      meteor deploy
    

and have a fully monitored application up and running on AWS with Meteor's
monitoring and deployment tools. Meteor's play is in the ease of these tools.
It is absolutely non-trivial the amount of glue and knowledge you need to
create, understand, and maintain the current (and ever-rapidly expanding)
Javascript toolchain.

This announcement touches on one of their most thorny issues of being tightly
coupled to Mongo. Adding this abstraction layer allowing any UI and any data
source is Meteor's ticket to the masses.

~~~
enobrev
I think I get your point, and while I haven't done much with meteor since a
few weeks after it was first announce, I recently started a couple react.js
projects using jspm. I'm not sure, yet, if jspm is ready for prime-time, but
getting started was as simple as:

    
    
        npm install [-g] jspm 
        jspm init
        jspm install react
    

For es6/es7, adjust config.js babelOptions.

I've nothing to add in regards to ios / android / desktop, but for getting up-
and-running, jspm seems to do the job quite well.

~~~
djmashko2
Can you use NPM packages with JSPM?

~~~
enobrev
Yes you can. NPM and Github. [http://jspm.io/](http://jspm.io/)

(I have nothing to do with jspm, I've just been using it recently)

------
davnicwil
Each successive post of the recent set from meteor just seems to be bringing
it further towards resembling the features of a GraphQL > Relay > React stack
- in fact actually using React, and now it seems, GraphQL.

This is great because the promise of a stack like this is _very_ exciting, but
I am left wondering what is meteor promising to bring that isn't just bundling
some modules, and re-implementing Relay?

I can't see anything in the list of _what we are planning to build_ that isn't
already offered by Relay, or on Relay's roadmap.

Not that a different implementation isn't a great thing, competition is always
advantageous, but my understanding is that Meteor is a for-profit company
whose product _is_ their framework - it seems quite odd therefore that their
plan for that framework appears to be to just piece together and/or re-
implement an already-existing, well-used and well-known stack of completely
open-source libraries, that aren't at all difficult to piece together as it
is. What's their strategy here?

~~~
primigenus
To be "The Javascript App Platform", as displayed prominently on the Meteor
homepage. If you build an app with Javascript, MDG want you to build it with
Meteor. In order for you to do that you need to trust that you can use the
tools you want to, and derive benefits from the fact that the stack is
designed to work as a single platform. So if GraphQL is where it's at, it
makes sense to design a place for it in Meteor.

~~~
davnicwil
Well yes, that's their general goal, but hasn't the developing React stack
already won on that front?

It frankly seems they at least believe it has, as it appears their plan is to
take it, bundle it together under one name and re-implement some parts.

The question is then, why would anyone on the React stack, which has become so
popular, switch to Meteor? The stack of libraries Facebook has already put out
there (not to mention third party libraries such as Redux) _are_ designed to
work together, and do so easily and very well - people are familiar with them
and already using them.

I suppose the only dimension on which they could coax people over from the
existing React stack, Relay in particular, is by developing its feature set
faster and better than Facebook can. For what it's worth I think it's a good
thing, I just find it pretty intriguing if that's their play - going up
against the popular tide and basically directly competing with Facebook on
bundling together their own libraries. Will be great to watch their progress!

~~~
primigenus
Has it won? Where can I go and write `react-stack create my-new-project` and
get a guaranteed working integration of the various elements that make up the
stack, including a working server environment, pre-installed and configured
database, and all of the other inbetweens that come with Meteor (such as DDP,
livequery, Tracker, Blaze, ReactiveVar, etc)?

The "React" stack has certainly been an up and coming potential competitor for
Meteor, but until Facebook or someone else actually shows signs of preparing
the kind of integrated development experience that Meteor ships with out of
the box, I don't think it's really similar. So that's what they're doing:
tying together the best of the Javascript ecosystem, which happens to
currently include a couple of projects by Facebook, into one cohesive whole
that "just works".

~~~
rapind
Is "react-stack create my-new-project" really preferable to something like
"git clone git@github.com:react-stacks/react-firebase-template.git my-new-
project" ?

I'm sold on the latter, since often enough I'll customize and publish my own
tweaked templates as I become enamoured with different tech.

------
Matthias247
Is Reactive GraphQL even specified? I thought that in the current state
GraphQL only defines single queries (snapshots) of data, and not continuos
update notifications. Forgive me if I have missed it - I have not followed
GraphQL/Relay apart from a very basic look at it.

Without having an open specification Meteors implementation might end up
completly different or incompatible to other (Reactive) GraphQL
implementations.

Despite that, I think that implementing a reactive GraphQL backend will be
very hard, and it would only work good if all of the sub-data-sources that you
use in your backend support reactivity (subscriptions) as well. If they do,
then you have to subscribe to all possible data sources that are mentioned in
the query, and update the current state when one of these changes. If the
update requires you to fetch an additional data source (e.g. you must fetch
other indexes of data which are provided by another source), you must even
dynamically subscribe/unsubscribe on updates of other sources.

And how can you provide traditional REST APIs (or even query-based GraphQL
endpoints) as reactive endpoints? The best you can do is probably implement
polling (rerunning) the query on the backend over and over.

~~~
rapind
The idea of changefeeds / subscription cursors has been around for a while
now, especially in Meteor. I doubt it'll be that crazy to add reactivity to
graphql queries when compared to what Meteor is already doing w/ subscriptions
and DDP.

RethinkDB for example has changefeeds built in and is tackling this problem as
well. See:
[https://github.com/rethinkdb/rethinkdb/issues/3711](https://github.com/rethinkdb/rethinkdb/issues/3711)

Data as a stream is pretty interesting too:
[https://www.youtube.com/watch?v=fU9hR3kiOK0](https://www.youtube.com/watch?v=fU9hR3kiOK0)

~~~
Matthias247
That doesn't really contradict my statement. I agree that the feature is
already there in Meteor (only with another query language), and that it's also
supportable by RethinkDB, Firebase or any other backend/db which supports
subscriptions. By what I meant is that it requires support for subscriptions
all along the chain, and this is not supported by legacy REST/GraphQL/etc.
APIs. The lack of alternate DDP backends besides the MongoDB one (and of
course the creation of custom subscriptions) seems to confirm this.

I am sure they could now update their query language to GraphQL instead of
MongoDB queries by adapting and extending the existing system, but I don't
know if thats currently the biggest problem for meteor adoption or only
something that is nice to have for some GraphQl/Relay fans (which still might
be using these directly anyway).

------
daxfohl
I'd recommend rebranding and a big-bang launch. Enough people were put off by
meteor that incremental improvements don't excite. Kind of the opposite of the
boiling frog thing.

------
d0m
What about offline support? This is one of the most tricky part.

~~~
joshowens
Offline support is tricky because each app needs to implement what happens in
the case of data conflict. Meteor already has the groundDB package that allows
for offline support in local storage. I would imagine you could implement a
read only option into local storage once they release reactive graphQL.

~~~
djmashko2
We have some thoughts about how the new invalidation system will make offline
a lot more feasible. In pub/sub based Meteor apps you would need to reload all
of the data if you took too long to reconnect, in the new system you will
hopefully be able to get just the diff after a much longer reconnect gap, or
possible indefinitely depending on implementation details. This is because the
app server doesn't need a copy of all of the client's data anymore.

------
rottyguy
Is anyone playing with GraphQL outside of js? Am interested in using it for a
project at work and wondering what's it like in something lower like c/c++.

~~~
estefan
I've been playing with a scala implementation called sangria ([http://sangria-
graphql.org/](http://sangria-graphql.org/)). The type safety of Scala has
really been helpful for refactorings and creating the schema. I can't imagine
the mess I'd have been in if I'd have used JS.

------
jFriedensreich
i would be interested why they decided against falcor style json graph instead
of graphQL

