@hluz it would be great for MDG to work on so many things, but they have limited resources. It’s up to us the community to support them, heck they gave us Meteor for free, and MIT licensed…
@moberegger I’ve hit struggles as well, outdated documentation on their website, but after doing some digging, looked at other’s boilerplates, I managed to hook it up. My vision is to have a meteor/apollo-super package, that gives you:
- Painless reactivity (that works with redis-oplog)
- Websocket stiching and Meteor user accounts integration, out of the box.
- Is properly merging with Grapher (Grapher is still the bomb.)
- Ability to have… reactive data graphs! But it won’t be the main focus I just explored the fact and it’s possible.
@alawi yes. it’s almost reinventing, it’s more like adapting the beautiful concept that MDG came up with, and putting it inside GraphQL. My vision is to hack something to make GraphQL as simple as possible. The reason I started adopting GraphQL is that I was pondering about evolving Meteor’s API in something self-documentable, something better decoupled (https://github.com/cult-of-coders/mutations) and what I realised is that I was slowly reinventing GraphQL… so I said to myself STOP! and got on the bandwagon.
GraphQL beauty lies in it’s ability to self-document itself, it will become a standard and will be widely known by many developers. I can simply write backend code, expose my schema, my mutations, put in a graphql mocker, and the frontend engineer can already start coding without needing my implementation… it’s very lovely, and there are many advantages to it…
Anyway, that “Simple” part is what I’m working on (in my spare time)