He have been using GraphQL at Kadira for about four months. Now we are starting to write Meteor UI components using GraphQL. That’s where we started this project. (And as a christmas gift)
Basically, this is an alternative data later for Meteor. We can use this side by side with Meteor pub/sub & Methods.
I have to say a lot. Check our blog post:
This is great @arunoda ! I can’t wait to try it out!! I’ve been loathing the publications lately because I have to drop down to the low-level API so much. This is much better!
Yeah. We also had an user who is having some issues memory issues with pubsub.
I’m just curious (sorry haven’t tried it yet) but will this compose with Redux connect in case a component needs botg local state and DB data (from GraphQL)?
I presume I could wrap Comment in connect before or after wrapping with the GraphQL container and then both data sources would show up in props?
I briefly looked over the tutorial. One thing I’m not sure about this is: Is this React exclusive or can we tie this in with every technology, say Polymer or Blaze for example? I believe it’s possible, am I right?
Yes. It’s possible. I’m trying to build some tracker related tools as well.
Yeah! It works with Redux as well. Here Comment.fragment is just a placeholder.
@arunoda, what is your opinion of when this would be a great fit?
Some example questions… (disclaimer: I certainly don’t expect you to answer any of these, just hoping to parrot some things others might be thinking).
Do you see it as relatively production ready?
What are the biggest short-term and medium payoffs?
Do you think it would make sense to transition a fairly stable production app towards using graphQL?
Any thoughts on how to do such a transition in small steps?
Generally my approach is to leave it be if it’s meeting your business needs. However, i’m always prone to experiment with new things and a lot of times I will re-write it in my free time with no plans of making this production ready/useable (i’ve done this with Elixir many times)… this way you can learn and make a better decision if it’s hype and if it solves problems for you (and… you get to play without any worries 
) .
@arunoda Exciting features! Out of curiosity, are you planning to use DDP for realtime GraphQL support? I’d be interested to see the mapping of GraphQL to a realtime wire protocol, as we are planning to slap GraphQL on our realtime datastore as well and if we do, we might as well do it in a way that integrates well with others.
Do you see it as relatively production ready?
We just released it. APIs are stable for 1.x.x. We tested a lot. We may have bugs.
What are the biggest short-term and medium payoffs?
Lack of Meteor/Mongo like realtime ness. You need to work a bit more to do mutations. You need to learn GraphQL.
Do you think it would make sense to transition a fairly stable production app towards using graphQL?
Yes.
Any thoughts on how to do such a transition in small steps?
First identify non-realtime parts in your app. Make them as a GraphQL schema. Use it in the client.
Realtime GraphQL/subscriptions is still on the experiment level. And there won’t be a single transport layer because of the nature of GraphQL.
Our realtime support for GraphQL will be based on DDP. (We just wanna use WebSockets).
Lokka will be transport independent.
There’s a great question on twitter asking whether if we can use this with Meteor’s reactive data source.
Here we use GraphQL.bindData react utility to bind a GraphQL query to a component.
See:
SysInfoContainer = GraphQL.bindData((props, onData) => {
return SysInfoSchema.watchQuery(SysInfoContainer.query, onData)
})(SysInfoComponent);
SysInfoContainer.query = `
{
sysInfo {
...${SysInfoComponent.fragment}
}
}
Then it’s just another react component we can use anywhere. So, we can use it inside a getMeteorData component as well.
See:
const ReactiveComp = React.createClass({
mixins: [ReactMeteorData],
getMeteorData() {
return {
posts: Post.find().fetch()
}
},
render() {
return (
<div>
{/*Do something with this.data.posts*/}
{/*Then simply use SysInfoContainer inside that:*/}
<SysInfoContainer />
</div>
);
}
});
@arunoda why not go straight for a Relay implementation. I don’t see how I or anyone could justify writing code like this when any day now we will be doing the same but using the Relay interface instead. Maybe the code is not so different given ur using a similar higher order component technique. In that case, id like to know what the migration strategy would be when full on Relay is ready??
Actually, Relay is not GraphQL. It’s something build for React data cache. It’s so hard to get started with Relay.
That’s why I don’t added it here. But creating a Relay transport also not that hard. I am open for PR.
Our goal with Lokka is to create a GraphQL cache work everywhere. It doesn’t has to do anything with UI frameworks or architectures like Redux.
GraphQL is the core data layer at Kadira. We use Lokka for talk between severs. It will be used in our UI as well. There are some people looking to use it with Vue. It’s possible to use with angular as well. Tracker bindings will come soon.
That’s why we don’t go with Relay. But it’s extremely possible to use it if you are good at it. I’m open for a PR for Relay transport.
I agree Relay is hard. Creating GraphQL schemas is even harder. So I’m definitely not opposed to abstractions that make all this stuff easier yet inter-opt with it, thereby giving it access to its emerging ecosystem.
But–and I don’t wanna come off as thinking ur amazing work here is anything less than awesome–u give an example of using it like a relay container. So it just makes me think ur missing out on the main marketing move for what u have built. It’s a lot more compelling of a story if u can tell meteor developers they can use full on relay today, rather than a more general (yet simpler) cache wherever u want to use GraphQL.
I’ll look into ur code. Perhaps I’ll be the one to submit that PR.
…that all said, the holy grail here is obviously relay subscriptions. Perhaps ur more focused on getting subscriptions to work here without Relay since Relay doesn’t yet officially support subscriptions. That’s a sound path towards building up ur Arsenal in order to be ready for when Relay does support subscriptions. Then at that point fully support Relay all at once. Meteor developers will have a hard time grasping and making use of Relay coming from a system that already supports subscriptions until Relay also supports it. I think a lot of people in the Meteor community likely think Relay already support subscriptions, when in fact if u put it to use today, u wouldn’t get any of the realtime goodness ur used to that Meteor has provided for years. Not without a lame interval polling strategy at least.
Ok, so first React replaced Blaze, now GraphQL replaces most of the rest of Meteor! Lokka replaces Minimongo cache… What is left? Meteor stack is being deconstructed quite thoroughly 
I’m curious how easily I can integrate graphQL into my app… I don’t think I will miss subscriptions much.
However, one thing I will miss is the ability to shove anything into my mongo documents, without worrying about a schema. This is a great feature for rapid prototyping and development.
For example, in my own “RAD framework” Celestial I’m developing, I use a lot of “autoform” components, and I use a generic update function like this:
Celestial.updateItem = function (props, field, value) {
const dotKey = props.dotKey ? `${props.dotKey}.${field}` : field;
let obj = {};
obj[dotKey] = value;
props.collection.update(props.item._id, {"$set": obj})
}
then in my generic “autoform” components and different UI components I can easily save data:
Celestial.updateItem(this.props, this.props.field, e.target.value);
This may not look like like very clean and “safe” code, but it works like a charm, and I can develop my app fast!
So I would like to be able to do the same with this GraphQL implementation, but I don’t know if I can do it, since everything needs a static schema. Is there any way to add dynamic fields?
First, awesome @arunoda.
Second, I am going to quit programming and become a psychic detective like Shawn Spencer.
Who wants to be my Gus? Anyone, anyone!?
I’m kind of glad that @arunoda isn’t thinking about the main marketing move and instead doing what he seems to do best which is building awesome stuff that works really well. I’m tired of all the buzzwords around React, I would rather have something simple that works well.
I spent about a year trying to figure out what I need Flux for, which I still haven’t figured out, and it will probably take me at least another year to figure out what I would need Relay for.
@vonwao it sounds like ur tired of all this new stuff to learn and what not, right? Well by doing spinoff solutions it’s only making it harder. I’m not trying to take away from what @arunoda has done. It should be implied that he is a God, King of meteor community contribution. He already knows he has my respect; I’m just getting straight to the points I see which he may have missed. …Marketing is important and unless an order of magnitude more in value is provided I rather see efforts go towards enhancing what’s winning the marketing race. That’s one of the number one problems right now in the JavaScript/NPM community and what is driving developers in the meteor forums up the wall: there’s too much choice. I rather just see the likely winners complete their visions and sooner achieve the winner takes all dynamic they will inevitably achieve.
In addition, there is a huge demand for relay + subscriptions. There’s a huge demand for Relay to become more than theoretical and talked about and actually useable. That’s just my hunch. Similarly it’s my hunch general GraphQL caches are not on the top of everyone’s mind. They are for Arunoda, likely cuz he’s a god and because he has internal use for them. But most of us just want Relay to work with the mongo collections of our meteor apps already; and specifically as explained on the Relay site–we already have enough to learn. That same sentiment seems to be what u @vonwao are expressing right here. It’s the way many in the community seem to be feeling. That is if we are open enough to move forward and let go of the past. I personally don’t wanna wait around any longer holding on to tracker and less-scalable LiveQuery-based pubSub if Relay and GraphQL is destined to overtake it. Arunoda has already aknowleged at least the GraphQL part is superior. I don’t think stopping there is a wise decision when Relay is the final link that brings it all together, that brings GraphQL to life. I was talkin with Arunoda on his Medium article, and correct me if I’m wrong: basically ur main goals are a) relay is too complex and there should be a simpler interface and b) u want to use GraphQL caches outside of just react components, and c) relay doesn’t officially support subscriptions yet. Correct? Unless there is anything I’m missing, Arunoda, man, I think ur missing out on a big opportunity. This isn’t enough reason. If it’s time to replace blaze, our pub sub model, etc, it’s my best guess that the community just wants the complete react solution to compare to already. It’s painful being spoon feed each piece incrementally–even tho it at least is being “spoon fed” lol. I’m just saying if ur trying to reach the biggest audience and it’s not just cuz u need these tools internally, ur missing the audience. We want relay and react to fully support subscriptions so we can pull the band aid off and switch from Meteor.publish/subscribe and Blaze already.
And if there is scalability issues with a catch-all GraphQL mongo adapter just like there is with LiveQuery, that’s fine. The point is we now have a perfect upgrade path: we can go in and modify the generated GraphQL resolutions for areas where plain mongo won’t scale. So unless it’s not possible to replicate LiveQuery with GraphQL, it’s one of my strongest beliefs that nothing could be more important right now for the Meteor community. We need a GraphQL abstraction for mongo as simple as possible to what we have now that generates schemas, mutations etc, and seamlessly provides Relay with subscription support.
That said there is certainly a need for GraphQL client side caches outside of Relay and as @arunoda points out it’s not on facebook’s roadmap to focus on its integration with anything else other than React. Nevertheless, React + relay + subscriptions and a few implemented dbs is the holy grail here. And would do wonders for us all. I’m not sure this will get as much attention. It’s also realtime finally for the rest of the community outside of Meteor who only ever really had Firebase and wasteful polling. This would be a big deal for the greater NPM community and definitely lead to Relay finally taking off. Once it has this it will likely take off over night.
Ps. @vonwao new Mongo.Collection(‘foo’, simpleSchemaMap, true). That’s my recommendation for an API that generates a GraphQL schema for a collection and some basic mutations like insert, update, etc. passing true allows you to have arbitrary fields not defined in the schema whose values are returned by all queries on the collection. GraphQL is flexible enough to have the generated resolve functions operate in such a meteor-esque way.