12 ms·

Reactive GraphQL

158 points by johanbrook 11y ago

davnicwil 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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".
      - vpears87 11y ago
        Agree. React is a library. Meteor could complement React as a framework much like angular.
      - rapind 11y ago
        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.
    - girvo 11y ago
      I'm a React fanboy, and use it and React Native in production on some pretty large apps. However, Meteor adopting React (and related tooling) still has merit, as to build those projects required me to wire them all together, enforce convention for the other developers using it so that we didn't try to use the tools in ways they weren't intended, and work around the various issues that crop up when doing Unviersal Javascript. Meteor can solve all of these, and can market themselves as that integrated solution. We all win, in that case.
      - Keats 11y ago
- holonio 11y ago
  I think one of the biggest reasons for why it still makes sense to have a monolithic framework is server-aware React components. Most SPAs and React applications re-use tons of stuff like login pages, news feeds, etc. Most of the time, we can re-use some of the frontend UI stuff but end up having to hook it up with our backend manually. But, if we used Meteor, the components can interact with the server side. This allows us to do stuff like use "<Login />" and just have a login page that works, in terms of both frontend and backend. The point is that Meteor's goal should be to allow people to build abstractions and re-useable that can step over the client-server barrier. That's pretty much only possible when you make assumptions about server and client, i.e. a monolithic framework.
- dfischer 11y ago
  In the end it's about the UX from Meteor's side. If they can take all these technologies and make it very easy to work with (without all the annoying boilerplate setup, etc) then it's a big win.
deleted 11y ago
[deleted]
d0m 11y ago
What about offline support? This is one of the most tricky part.
- joshowens 11y ago
  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 11y ago
    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 11y ago
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++.
- DIVx0 11y ago
  this site has some good info: https://github.com/chentsulin/awesome-graphql#lib-c https://github.com/chentsulin/awesome-graphql#lib-c
- nutate 11y ago
  The officially released facebook graphql query parser is written in C/C++ https://github.com/graphql/libgraphqlparser https://github.com/graphql/libgraphqlparser
- estefan 11y ago
  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.
bwhitty 11y ago
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.
- dfischer 11y ago
  Yeah, this is pretty huge. Looking forward to it.
- enobrev 11y ago
  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 11y ago
    Can you use NPM packages with JSPM?
daxfohl 11y ago
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.
Matthias247 11y ago
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 11y ago
  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 11y ago
    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).
jFriedensreich 11y ago
i would be interested why they decided against falcor style json graph instead of graphQL
deleted 11y ago
[deleted]

158 points by johanbrook 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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".
    - vpears87 11y ago
      Agree. React is a library. Meteor could complement React as a framework much like angular.
    - rapind 11y ago
      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.
  - girvo 11y ago
    I'm a React fanboy, and use it and React Native in production on some pretty large apps. However, Meteor adopting React (and related tooling) still has merit, as to build those projects required me to wire them all together, enforce convention for the other developers using it so that we didn't try to use the tools in ways they weren't intended, and work around the various issues that crop up when doing Unviersal Javascript. Meteor can solve all of these, and can market themselves as that integrated solution. We all win, in that case.
    - Keats 11y ago
holonio 11y ago
I think one of the biggest reasons for why it still makes sense to have a monolithic framework is server-aware React components. Most SPAs and React applications re-use tons of stuff like login pages, news feeds, etc. Most of the time, we can re-use some of the frontend UI stuff but end up having to hook it up with our backend manually. But, if we used Meteor, the components can interact with the server side. This allows us to do stuff like use "<Login />" and just have a login page that works, in terms of both frontend and backend. The point is that Meteor's goal should be to allow people to build abstractions and re-useable that can step over the client-server barrier. That's pretty much only possible when you make assumptions about server and client, i.e. a monolithic framework.
dfischer 11y ago
In the end it's about the UX from Meteor's side. If they can take all these technologies and make it very easy to work with (without all the annoying boilerplate setup, etc) then it's a big win.

deleted 11y ago

[deleted]

d0m 11y ago

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

joshowens 11y ago
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 11y ago
  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 11y ago

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

DIVx0 11y ago
this site has some good info: https://github.com/chentsulin/awesome-graphql#lib-c https://github.com/chentsulin/awesome-graphql#lib-c
nutate 11y ago
The officially released facebook graphql query parser is written in C/C++ https://github.com/graphql/libgraphqlparser https://github.com/graphql/libgraphqlparser
estefan 11y ago
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.

bwhitty 11y ago

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.

dfischer 11y ago
Yeah, this is pretty huge. Looking forward to it.
enobrev 11y ago
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 11y ago
  Can you use NPM packages with JSPM?

daxfohl 11y ago

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.

Matthias247 11y ago

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 11y ago
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 11y ago
  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).

jFriedensreich 11y ago

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

deleted 11y ago

[deleted]