Thanks @vonwao, it helps a bit. So in general I should see it as “a” first step that decouples (in our case) Meteor from it’s rigid data layer (Mongo) and make it more flexible to support other Data sources as well. So it’s something that has been done (multiple times) in the past with other packages (e.g. the waterline example I gave, which I haven’t used btw, or Knex is also an example I think), but this is the first time somebody is doing that for Meteor, and @arunoda happened to choose (for valid reasons I don’t doubt that) to use the GraphQL spec to dive into that route?
So nothing specific about GraphQL I should know of. Just “a” route to the solution for database decoupling?
disclaimer: don’t read this as a negative comment, I’m just trying to wrap my head about the place in the eco system all these libraries represent. So I’m asking the stupid questions
That’s one way to look at it. But even if you want to stick with Mongo, GraphQL may provide enough advantages to switch. But you don’t even have to switch, you could use GraphQL where it’s appropriate and “Meteor livedata” where it’s appropriate. I think minimongo and Lokka could coexist well (?)
You may want to learn GraphQL. It’s a great technology that’s gaining momentum, especially now with the backing of kadira and @arunoda. I guess Facebook backing is ok too… But I think they are more focused on the spec and pretty hands off on concrete implementations.
Something tells me come Feb 22 at React Conf, they will address this head-on. Relay doesn’t yet support subscriptions. Most people are obsessed with Redux, and I know not a single developer actually using Relay. Discussion of subscriptions in Relay and GraphQL github issues has been silent since October. My conclusion or at least hope is that Facebook has something up their sleeve to really blow Relay up come their conference.
There’s a lot of promises that Relay hasn’t delivered on yet, such as synchronizing not just with remote server side datasources, but also client side ones or any you want, similar to Om Next in Clojurescript. That will replace the need for Redux.
There also needs to be more concrete implementations of Relay. I assume Facebook is aware of that. A smart move in this case would be to just do it themselves. Similar to how Google went ahead and started making their own phones (i.e. the hardware) to get Android to be taken seriously back in the day.
Either way, something needs to happen to break the Relay camel’s back. Relay + GraphQL is super effective stuff. But something needs to be completed before they take off. Nobody’s gonna be more aware of such things than its creators. …Basically this occurred to me last night after I had been basically begging @arunoda to just focus his attention on this stuff–Facebook’s gonna bring Relay mainstream just in time for this conference, and addressing realtime plus some concrete Facebook-sponsored implementations is the ticket. That’s my prediction.
Hmm, maybe, but look at it another way, Facebook has already succeeded at taking away a lot of mind share from competitors like Angular, Meteor, etc. What do they really have to gain by spending a lot of development effort on Relay, what’s their motivation? I’m sure at some point they will offer their own stack “as a service”, something like Galaxy or Google app engine/cloud platform (whatever they are calling it today). But I see Facebook as being ahead in the game, I think they are in no rush now.
well, it’s Facebook’s style to release something big at each of these events. Also, u have to think these products are really run by engineers at the company who are their true creators–they wanna see them succeed. I imagine somebody behind Relay wants it to explode, regardless of Facebook’s expectations.
I hope they complete Relay, rather than introduce yet more stuff.
@arunoda
Worked awesome for me, thanks a ton!
I started making a demo list with React-Meteor-GraphQL-Mongo, then swapped out MongoDB with PostgreSQL in about 30min using sequelize (with Meteor 1.3-beta NPM support!).
Demo Here. (Not currently working due to Galaxy not working with Meteor 1.3-beta and NPM Packages) Github Project updated with ReadMe and Heroku connection.
Just finished exploring your GraphQL course and meteor package. Amazing stuff!
In your opinion, would GraphQL be worth using with Meteor if I were to only be supporting a single MongoDB database? My initial impression on GraphQL is that it shows most of it’s value when trying to utilize multiple databases and/or database types. Please correct me if I am wrong.
This is something I would definitely love to try out, but I am also afraid of over-engineering my solution.
