Is it possible for someone to build an Apollo tutorial?

apollo
61

Thanks! A little note regarding async/await: it’s best if you understand a bit of the history of dealing with asynchronous stuff in javascript.

The original approach was using callbacks: asynchMethod(function(err, res) { react here })
Then came promises promise = asyncMethod(); promise.then(function(res) {}).catch(function(err) {})
Then came async, which works with promises in the background: try { res = await asynchMethod() } catch(e) {}

62

Quick tip that could help someone.

I struggled with Apollo Client mutation updates. I’m using meteorClientConfig() with Mongo and Rethink.

meteorClientConfig looks for the Mongo _id. My Rethink database uses id. This solved my updating problems…

const meteor = meteorClientConfig();
meteor.dataIdFromObject = result => {
  if (result.id && result.__typename) {
    return result.__typename + result.id;
  }
 if (result._id && result.__typename) {
    return result.__typename + result._id;
  }
  return null;
};
const client = new ApolloClient(meteor);
1 Like
63

I think, it must to be here https://www.learnapollo.com

1 Like
64

Githunt using polymer as the view layer. https://github.com/aruntk/GitHunt-Polymer.

Built using polymer-apollo package https://github.com/aruntk/polymer-apollo.

1 Like
65

Yep, my beautiful beautiful postgres how I miss you.

I’m trying to right apps using highly relational data and MongoDB doesn’t lend itself towards that in the same way a relational database does.

I do really love Meteor though and would like to stick with it.

66

Yeah good find! Our friends at Graphcool, a GraphQL backend as a service, produced this resource to teach people about Apollo Client. Just launched yesterday! It is a great resource to follow and they have an endpoint already set up for you, then after that you just need to learn how to set up a GraphQL API.

67

It seems you can nest / cascade mutations:

After reading somewhere that:

The only real difference between a mutation and a query is the word mutation. Interestingly, there is nothing stopping a query from including a side effect just like a mutation.

It made me think and try. And it turns out you can just as easily nest mutations.

Say you have an app with several distinct scenes. Your query could be something like:

schema {
  query: Query
  mutation: Mutation
}

type Query {
  #parent query for scene 1
  sceneOne: SceneOne
  #parent query for scene 2
  sceneTwo: SceneTwo
}

You can make the same kind of system for your mutations:

type Mutation {
 sceneOne: SceneOne
}

Now, your sceneOne queries AND mutations both point to the same SceneOne type. Your SceneOne type could be defined as:

type SceneOne {
  someSceneData: [ String ]
  someOtherSceneData: [ Int ]
  mutations: Mutations
}

someSceneData is a query for that particular scene, and mutations contains all your Mutations for that scene:

type Mutations {
  setSomeSceneData( myVar: String!): Boolean
}

In this way, you have one GraphQL-tree where your mutations are nested side-by-side your queries. Another way could be to build 2 parallel trees ,one for queries, one for mutations.

I actually have no idea if it is a good idea to nest things like this or not, but to me it seems a lot more organized and structured.

1 Like
68

Please update the Apollo tutorial for the latest version, in particular this page:
http://dev.apollodata.com/tools/graphql-tools/guide.html
and

A tutorial should use the latest version, not an old version with instructions to later migrate to a newer version.

1 Like