I’m also interested to know about Apollo’s timeline, in terms of its recommended use in prototypes and then production apps.
I’m keen to build an MVP for a new project which needs to read data from a legacy system’s MSSQL database.
I’m a new-ish developer, having built a few things with Meteor and I recently caught up with React. Apollo, along with sequelize seems like a great way to make a start on this project.
Could anyone from the Apollo team please let me know the best time to jump on? I look forward to the tutorials.
Please no. I absolutely loathe video tutorials about coding.
Though you could improve it by printing the code, putting it on a wooden table and then filming that.
With the text form I can skip easily to the parts which interest me when the author begins to waffle about something else. Or sounds like a donkey inside a metal tube.
Also, I can read code way faster than a video will ever be able to provide information.
I enjoy videos! especially coding videos because you get to see every step live and while the composer explains what is going on …then the code can still be accessed on github. Every person has their own best way of learning
Hey just an update - tomorrow we’re starting a two week sprint focused entirely on docs and other educational materials. We’ve been pretty heads down just implementing features and fixing bugs and it’s time to shift the focus! It probably won’t have a full tutorial in the next few weeks, but at least things will be far easier to get started with.
Hi all, I pieced together information from a couple of the Apollo blog posts and docs and took a stab at creating a simple Hello World app using Meteor and Apollo. I also blogged about it on our Project Ricochet site. It might help you get your feet wet with Apollo and Meteor.
So many good things popping up lately from Apollo - SSR, React Native…
As your post says - its ambitious. MDG perhaps play it down as its still in preview: I have a feeling it’s going to be phenomenal. Like scaphold on steroids…
@mbanting Thank you for the amazing tutorial and source code. As a beginner, I found myself struggling just to get started with the overly complicated examples, and was getting discouraged, but your tutorial was able to clearly communicate how to tie together the full-stack GraphQL/Apollo/React/Meteor to me. Perhaps you could add an example of a GraphQL mutation, subscription, and adding another database as well? Although I’ve already seen how to do that in a few places and it doesn’t look too bad, feel like that would be super helpful while still keeping it simple. Again, thank you so much.
A question that remains unanswered for me though: Meteor doesn’t seem to be doing much with that Apollo example. Why should I still use it? As a build tool? User accounts?
@mbanting; Your blog is writing that the only way of adding reactivity is add polling, but that’s not really true. Recently the apollo team came with subscriptions. Another thing missing from your blog is latency compensation; although that would be a hard subject for beginners. So maybe it’s better to just mention this.
See here:
But most of all; what I’m missing in your blog, is why you still use meteor. You chose for Apollo, React and Sequelize. What I’m interested in; what role you see for the Meteor part of the application. Just a build tool? Or am I missing something here?
Because you don’t use Blaze, Mongo, Publications or Methods. A few things that makes Meteor, Meteor.
Probably heresy and flameworthy, and somewhat obscured by the transitionary period, but I like to think Apollo is Meteor (2.0)
Still loving classic Meteor though.
@smeijer, ya I saw that too. Between the time I finished writing my post and the time it was published, the GraphL Subscriptions in Apollo Client post came out. Things can get outdated pretty quickly when writing about a preview or beta release . I’m thinking about writing a followup post, as @roachman suggested, to address mutations and subscriptions, but may hold off on things that may be impacted by Meteor 1.5, like user accounts.
In regards to your other question, I wanted to keep this a very simple Hello World exercise. Obviously from here you can add all the other Meteor ‘stuff’ on top of this, or use this as a guide to incorporate Apollo into your existing Meteor app to work in parallel with Mongo, Methods, DDP, Accounts, etc.
Things are evolving and patterns of how to better incorporate or more tightly integrate these Meteor packages and APIs with Apollo will eventually arrive, hopefully as early as Meteor 1.5.
I’ve been struggling with this question too. As much as Apollo is decoupled from Meteor, I remember one of the Transmission broadcasts where Apollo was referred to as the “spiritual successor to Meteor’s data system”. So does that infer that Apollo is future Meteor?
As long as we get an instruction sheet which actually explains the syntax step-by-step, I’m happy.
Because currently it’s a bit confusing to discern which bit goes where - especially because queries, schemas and the like all seem to be named the same, save for liberal CamelCasing (or not) of the names.
Something like:
This is how you create a schema
This is how you create a Model from the schema
This is how you query the Model
This is how you query two interconnected Models (i.e. JOINs)
This is how you connect the Model to the database.
And so on. Basic stuff. The current documentation is still assuming too much foreknowledge.
What do you mean by explains the syntax. Did you look at the GitHunt-API project? It gives examples how to create a SQL model, etc. (some things are not that obvious, like joins).
There’s actually a lot that basic examples don’t cover, like the fact that you usually need both an output schema and an input schema for your graphQL types (assuming you need ability to query and also mutate your data).
So I agree that more detailed instructions/examples could be provided…
️
Perhaps you could add an example of a GraphQL mutation, subscription, and adding another database as well? 
Although I’ve already seen how to do that in a few places and it doesn’t look too bad, feel like that would be super helpful while still keeping it simple. Again, thank you so much. 
. I’m thinking about writing a followup post, as