Yep. I get it.
It’s really cool to have Schema less for early prototyping.
There is a suggestion to add JSON type to GraphQL. But I don’t think that’s gonna happen soon.
Here’s my take on this;
At the initial state, you need to verify the idea and build a MVP. Use meteor with mongo using current data layer.
When it’s time to scale, try moving parts of your app to GraphQL with a database works for you.
That’s what we’ve done at Kadira from the start. GraphQL makes it easy.
Ha ha.
Anyway, I was looking for this tweet to make a reply. Thanks 
Ok, well… I don’t see the point of discussing so much.
What I advocate is let real use cases inform a useful implementation, instead of getting too caught up in concepts and abstractions. I think this is how Meteor developed, it evolved slowly based on real needs, real use cases, not by some standards or “architectures” like Flux and Relay.
GraphQL subscriptions sounds like a wonderful idea. I’m still not sure why “Relay” is needed for this. Why don’t you code something up that builds upon kadira:graphql and uses DDP for subscriptions? Whether or not you implement Relay is up to you, but subscriptions are needed either way, and the API and implementation can be adapted and tweaked later.
Less talking and more coding 
Also thanks for the suggestions, I don’t know Mongo.Collection(‘foo’, simpleSchemaMap, true), what exactly is simpleSchemaMap in this case?
I think I just need to visit Sri Lanka to meet with Aronoda.
Maybe there are some air special?
You created great app learngraphql.com, i will use it for non-reactive data. This is really new age of rest api
Does defining data fetch client side makes it harder to do permission filtering?
Nope. Inside the server side schema, you can do the permission as usual normally you do it with a Meteor method.
See: https://github.com/kadirahq/meteor-graphql#authorization
Client may be asking for any kind of data, but you can give from the server what you want.
Also inside the client, you can use different fragments for different types of users.
i got this error when called from other client app:
Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access. The response had HTTP status code 500. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
I assume this is related to a node app (not a Meteor) with Lokka. Then you need to enable CORS like this: https://github.com/arunoda/learn-redux/blob/server-side/server/graphql.js#L8
i’m using kadira:graphql to make graphgl server, so how to use cors ?
is there any config in your package?
Oh! When you are using kadira:graphql you can only connect to it via Meteor only. Could you submit an issue on GitHub with more info.
I hope that’s a good place for these type of discussions.
Sorry if this is a silly question, blame it on the js world going faster than light at the moment 
I’m just wondering where to place GraphQL exactly? What is it? Is it just another ORM like package? What’s it’s point? To me it just feels a whole can of worms on itself, but for what purpose. Is it comparable with something like https://github.com/balderdashy/waterline?
Cheers
Yes it’s from Facebook and he uses it since longer than 4 month so it must be real good 
But seriously, learngraphql is a great course.
So you’re saying fragments could be used for authorization… like different roles? I didn’t quite get that.
I’ll take a crack at answering your question @Ben. I don’t know how familiar with you are with Meteor, if you’re familiar with the Meteor story, and specifically the data layer, think of it as an alternative data layer, similar to Meteor’s in some ways, but different.
GraphQL is a general spec that can hook up to many different DBs. In this case @arunoda shows in his demo how to hook up GraphQL to Meteor Collection API (on the server). But it could be something else like SQL.
Then on the client kadira:graphql uses this new Lokka library, which is basically a cache plus some utilities to help you work with GraphQL. Think of Lokka as an alternative to minimongo.
The biggest thing that GraphQL is missing now is publications/subscriptions, basically a way to push new data to the client automatically (which is one area where Meteor shines). Also it may be a little more verbose than Meteor, think of it like a statically-typed language whereas Meteor favors a dynamic language. So it may have some tradeoffs in productivity vs quality of code and performance.
I agree with you 100%, this is really important! However, I think you reversed the companies.
Meteor was designed from scratch with assumptions about how most people would build their app. The core was decided on on day 1, with slight changes made over time. It wasn’t extracted out of a running production app (like Rails was). This is fine, but statistically you’re going to guess wrong on some things.
Flux was made in house and then it was extracted as a set of patterns. It’s made to help solve sharing transient data between React components (because they can’t reach out to siblings/parents like Blaze does).
Both flux, GraphQL, and Relay were built out of their own needs and were open sourced.
At any rate I think GraphQL is a really nice outlook on data access and can solve issues for certain companies. Using pub/sub is still going to be the best bet for day 1.
Ah nope. I mean different users may need different data requirements. You can define that in the client.
Yep. Very good answer.
and @Ben if you know Waterline and have existing schemas. There is a project to convert those models into GraphQL. See: https://www.npmjs.com/package/waterline-graphql
Hm, interesting, you reversed my story.
But, even if Meteor had an original vision of how development should work, I think they still evolved that vision quite gracefully to adapt to real needs.
Maybe: Meteor evolved out of RAD development/prototyping need, whereas React/flux/relay evolved out of a need for developing massive scalable app. For me, Flux seems too beaurocratic, I prefer Meteor way, as long as performance is ok.