Apollo is a huge step towards making GraphQL easy to use, but there’s still a lot that needs to be done manually. Loading data, executing mutations, writing your GraphQL schema, etc. all require some boilerplate.
In this article, I explain how VulcanJS approaches this and tries to make your life easier by providing some sensible defaults:
This is excellent, and something that I and probably many others have been looking for.
Could this be the answer to Apollo integration and 1.5 release - will it happen anytime soon??
I’m also wondering whether it would be better if MDG comes up with Meteor integration with Apollo as mentioned by @hwillson in July 2016 in Great News: Meteor/Apollo Integration Coming in 1.5 in which @benjamn is quoted as saying:
the current plan for Meteor 1.5 is to focus on Apollo/GraphQL integration, in order to support databases other than Mongo (among other important goals)
I’ve read the article yesterday, it was a very nice read and definitely a good direction. 
As long as it’s not a front-end agnostic answer (like Vulcan being tied up to React), it will be only a partial answer, so I expect from official Apollo/Meteor integration something different.
I’ve had a quick look at the code to look for use of meteor/apollo as described in:
Would it be better to use it, considering that it is an official package by Apollo developers?
Or were there reasons not to use it?
Since that time, we’ve changed the plans, as you can hear if you listen to some of the recent podcasts etc - Meteor as a project is not going to focus on Apollo integration in the near future, and instead is going to focus on the needs of current Meteor developers, most of which we have found are not that interested in Apollo yet.
Vulcan does use this integration, and in fact Vulcan contributors are some of the main maintainers of meteor/apollo!
I heard @sacha is already building some projects on Vulcan, so it could be something cool to try if you’re looking for convenience!
What I noticed in particular is that the Vulcan code declares createMeteorNetworkInterface at https://github.com/TelescopeJS/Telescope/blob/d195d366c8b7e6577a2d0226d2684f2d4714d0fd/packages/nova-lib/lib/modules/apollo.js#L16
instead of importing it like:
import { createMeteorNetworkInterface, meteorClientConfig } from 'meteor/apollo'
as shown in http://dev.apollodata.com/core/meteor.html#createMeteorNetworkInterface
I couldn’t find any import `from ‘meteor/apollo’`` in the code. So it appears that it does not use it.
The chronology of things is more or less that @loren worked on the first version of the meteor-apollo package, but then we realized that it didn’t quite do what we wanted, so @xavcz worked on building our own integration instead. Since then he’s become the main maintainer for the package, and he’s been applying what he learned working on Vulcan towards improving the package.
So although right now Vulcan doesn’t use the meteor-apollo package, both are basically being developed by the same person, and I expect they’ll converge pretty soon.
Also just to be clear, the meteor-apollo package only sets up the Apollo infrastructure, it doesn’t include the extra utilities that Vulcan provides.
So I believe Vulcan is the closest thing to a “Meteor/Apollo integration” in the sense of making Apollo as easy to use as pub/sub in Meteor apps.
That’s great to hear and I’m looking forward to it.
It also appears that @xavcz has been working on:
So could the starter kit be a first stepping stone for beginners, and when they are ready to move onto developing a fully-featured app for the real world they can look at Vulcan?
Would you continue to rename everything from Telescope and nova to Vulcan? I still see the old names in GitHub and Vulcan documentation, which could cause confusion.
@sacha do you think it would be possible to use some of your Apollo-related packages with different view layer?
I don’t think they’re really comparable. The starter kit is a minimal example meant to get you to understand how Meteor, Apollo, GraphQL, and React all work together by looking at the code. On the other hand Vulcan is a set of APIs built on top of all this. In other words it’s a bit like comparing Ruby and Rails, building an app with Rails is going to be a lot easier for a beginner even if the Rails codebase itself is a lot more complex than a Ruby starter app.
And yes we’re eventually going to rename everything to Vulcan, we’re just taking our time
Not really, sorry. They’re pretty tied to React. On the other hand you can reuse the same concepts.
Well, it was worth trying. 
I’ll investigate reusing the concepts then.
I already have to say I love you for the superb comments on the code. This is brilliant, all developers should follow this example.