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
A topic I’m still struggling with is larger schema and query organization:
All info and tutorials talk about a basic app. But how do you handle larger projects? For example an app with several distinct sections( a user-info page, a comments section, a todo-section, and so on)
- Do you create a long list of queries on the root?
- Do you try to nest them? ( eg. root-query -> user -> account -> readingprefs )
- what about mutations? All on the root mutation?
At the moment I’m trying the nested method, using some dummy queries as sections( like ‘users’). No idea if this is a valid way.
+1
I’m also curious about this topic, I currently immigrant my knowledge about Neo4j modeling (a graph database) to GraphQL, I think they have something in common.
And I believe F8 app is in on a good path, worth a referring.
Seems mutations have no way to cascade…
4 Likes
I’m using Neo4j and Apollo. I haven’t found a synergy between Neo4j and GraphQL that’s worth using Neo4j if it’s not a natural fit for your data.
That said, I love Neo4j!
Here’s what I’m doing. Feel free to criticize it as genius or moronic.
My queries are in one folder (you can separate them into folders as needed), mutations in another.
// queries/vehiclesToDisplay.js
const query = gql`
query VehiclesToDisplay {
vehicles {
id,
vehicleId,
Attributes {
year
make
model
boughtfrom
}
}
}
`;
export default query;
// mutations/updateYear.js
const updateYear = gql`
mutation changeYear($id: String!, $vehicleId: Int!, $year: Int!) {
changeYear(id: $id, vehicleId: $vehicleId, year: $year) {
year
}
}
`;
export default updateYear;
Then I use compose to put them together with the presentational component…
// vehicles.js
import UpdateYear from './mutations/updateYear';
import UpdateYear from './mutations/updateModel';
import VehiclesToDisplay from './queries/vehiclesToDisplay';
import Vehicle from './presentation/Vehicle';
import { graphql, compose } from 'react-apollo';
const options = {pollInterval: 5000};
export default compose(
graphql(query, options),
graphql(updateYear, { name: 'updateYear'}),
graphql(updateModel, { name: 'updateModel'})
)(Vehicle);
The Vehicle presentational component gets mutate and data.vehicles as a prop. To pass multiple mutations, set the name option, e.g. GqlHoc({ query: changeThis, {name: 'changeThis}), GqlHoc({ query: changeThat, {name: 'changeThat})
Known problems… the presentational component formats the mutation.
2 Likes
This looks pretty good to me. I really like the abstraction of queries/mutations, etc. I don’t have enough experience to know if this would be a problem for any reason.
I haven’t used recompose myself, but I would consider “recomposing” into a “container” component, as opposed to a “presentational” one to give yourself more flexibility in the future. For example, using fragments and then using graphql-anywhere to filter the query so you can displayVehiclesByYear, displayVehiclesByMake, etc
1 Like
I’m confused - isn’t graphql already and HOC? You can use it with compose and everything.
[quote=“sashko, post:57, topic:23416”]
I’m confused - isn’t graphql already and HOC? You can use it with compose and everything.
[/quote]I’m the one who’s confused. I thought that graphql had to invoke its second function. (I’m new to currying and still trying to wrap my head around it. I’ve gone into the Apollo source code, but I see it didn’t help me!)
After getting deeper into the docs, I see that I reinvented the wheel. Thank you for the correction. I updated my post.
1 Like
Great work @nmaro !
I need to study about asyncand await to understand it better, but I think it is great material.
I spent a few hours trying to wrap my head around all the apollo/graphql-server repos and their relation. Your post confirmed the ideas I had and how I understood the way they relate.
Thanks again for sharing!
meteor+apollo release date?