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.
5 Likes
Great post.
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ā¦
1 Like
@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?
2 Likes
@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.
1 Like
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.
3 Likes
Thanks for all your feedback.
@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.
2 Likes
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?
Apolloās a different animal for sure, so āspiritualā is neat phrasing . Im sure MDG will make it a cinch/joy ā¦and incredible possibilities opening up.
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.
3 Likes
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ā¦
Iām hoping eventually that the same (excellent IMO) Meteor Classic tutorials will be available for Apollo. That is, create a full (if simple) app in each of the supported view layers.
2 Likes
I find it amusing that youāre asking me what I mean by syntax and then provide a perfect example all by yourself 
But, no, examples are explicitly out. Examples can be an addition to a proper syntax definition, but NEVER provide only examples.
Thatās actually one of the worse habits out there - āhereās all the stuff youāll ever need, we just slapped you silly with it, make sense of it on your own!ā
If I tried to teach only through examples (and fully-featured examples at that) thereād be riots in my classroom. And even when Iām using examples, Iām always referencing the underlying structures, i.e. showing how one particular detail of this example relates to one general principle.
@rhywden would something like this work? https://www.codetours.xyz/tour/partyparrot/GitHunt-API-code-tour
Or do you think a step-by-step tutorial is unavoidable?
1 Like
Might work. For some it might it might still be a bit too much at once.
For example, this line of code on the first page:
feed(type: FeedType!, offset: Int, limit: Int): [Entry]
Itās not immediately visible where the Entry part comes from and what it means - I mean, I myself know that itās likely a return value and returns an array of Entrys
And on the next page, at the Entry schema,
type Entry {
repository: Repository!
...
where does the Repository come from and where is it defined? I mean, I can hunt it down but those are little stumbling blocks which throw you off a bit.
This CodeTour is something Iād propose as intermediate level learning. For real beginners, a step-by-step from fundamental principles and reduction to the most basic components would be appropriate. In my opinion, of course.
Also, the last bit There's more in this app that could be explained, for example how to load data from SQL is a bit of a copout in my eyes, because while the GitHub API may be easier, itās not something I myself am actually interested in. I myself would definitely want to know how to actually query a backend SQL db.
That part would probably benefit from branching: How to talk to REST backends like GitHub or Azure, how to talk to SQL databases, how to talk to NoSQL dbs and so on. And use that branching to show the backend agnosticism, that you could exchange MongoDB for PostgreSQL and still have the same frontend code, āonlyā needing to update the connector.
After all, isnāt that supposed to be the big advantage of Apollo? 
In my mind these are all just feedback about the quality of the content, rather than the presentation.
We were talking about a step-by-step tutorial, Iām not sure that it would automatically do a better job of explaining all concepts?
IMO non-linear tutorials are not something we should consider at this stage, because that might turn out to be really hard to maintain.
But for teaching purposes, quality of content and presentation are intertwined
You can have the world-best content but if you donāt present it correctly, you might as well not have bothered.
For example, when Iām assembling one of my Physics experiments, I always take care to present a non-cluttered surface, direct attention to the places where something is actually happening, rearrange instruments in the proper order and so on and so forth.
And if you donāt want to do branching, then at least consider using a backend thatās actually seeing real-world use
I guess I just donāt know how to incorporate the feedback - Iām not sure if youāre asking for a step by step guide with different technologies or a walk through of a production app.
Either-or would be fine. But the CodeTourās explanations are too broad in scope and need to be expanded, at least explaining references that will be covered by a later page.
In short, you need to go through every line of the code youāre highlighting and ask yourself: āDoes the viewer know how to make sense of this line?ā
1 Like
The code tour is wonderful. This is the kind of thing I feel like Iāve been waiting for. Once I got to the part about contexts, I was in completely uncharted territory. Iād never had this level of understanding before. Iād looked at resolvers before, but never gotten far enough to get what was happening. Everything past that was equally eye-opening.
Improvements that could be madeā¦
- The tour stops short of showing how data is stored to SQL which is also a pretty alien thing to me coming from a Meteor 1.0 mindset. Expanding the tour to cover how data is stored would be nice.
- An introduction that explains what GitHunt is, what it is designed to do, would be an ideal start. Iāve seen the example referred to dozens of times, but I donāt actually know what it does.
- The conclusion has a blurb that reads āXXX if we deploy in timeā A missing link, I guess?
1 Like
Iām currently writing a handbook about GraphQL, in Chinese, and translating to English in Async.
Here is what I think it should contain:
Basic:
- Go through building steps: Modeling -> Schema -> resolver func -> setup server and client -> query data
- Modeling: Types in Schema and Resolver
- Progressive Data Fetching: Pagination, walking through relationships and TUI
- Be like QQ!: Subscription, File Upload and more [RFD]
- Caching: Server-Side and Client-Side
Advanced: - Transition Period: Wrapping REST to GraphQL
- Sealing: Cascading Gateways
- Security: Hacking into GraphQL
- Future: GraphQL Anywhere
Can you come up with some other topic that I should cover?
2 Likes