DDP-Apollo 1.0.0-beta released with Apollo 2.0 support!

announce
13

I totally get why people like Apollo, and depending on the use-cases I see it as a better fit than Grapher, even if you are using Meteor. This is why this package is super nice and it’s the perfect integration and I thank you for that.

My main issue with Apollo is the fact that it breaks the core principles that made me love Meteor in the first place:

  • Very simple setup
  • Elegant & painless reactivity (and now extra scalable, I’ve been working with different companies, and redis-oplog simply rocked, can’t wait to post the case studies)
  • Elegant RPC (You cannot get more elegant than Meteor.call(‘functionName’, arguments) )

None of these are present in Apollo.

Regarding tooling and performance monitoring, Grapher queries are methods and publications, you can already measure performance inside the APM. No need to use Engine/Optics.

Grapher took inspiration from GraphQL and initially, believe it or not, it was using GraphQL! But in time I realized that I’m the JS world and this is crafted for Mongo and Meteor. By laser-focusing and depending on these technologies you create the perfect tool.

As a programmer that started coding at a very young age and was exposed to very complex problems and ways of doing things, I always come back to what’s simple. Apollo has a limit of simplicity it can reach because it’s a full data-layer that tries to make it work with any kind of database and make GQL available in any language.

That being said, I’m not against Apollo at all. It’s super good, and Facebook Engineers really solved the all-around data layer in a very elegant way, and again GraphQL was the source of inspiration for Grapher, without it, I wouldn’t have had the “a-ha” moment.

8 Likes
14

Great info and insights thanks for sharing @jamiter!

15

I decided to release the current version as 1.0! :tada:

There were a couple of improvements made, mostly documentation, and the API is stable at the moment.

To try it out:

meteor add swydo:ddp-apollo@1.0.0

Run into any bugs? Please report those in the repo!

7 Likes
16

Is a call to pubsub.publish() required in every mutation in order for client to automatically see updated data?

17

Why is PubSub from graphql-subscriptions not recommended for production?

18

From the documentation:

Note that the default PubSub implementation is intended for demo purposes. It only works if you have a single instance of your server and doesn’t scale beyond a couple of connections. For production usage you’ll want to use one of the PubSub implementations backed by an external store. (e.g. Redis)

The default implementation is in memory. If a user connects to server A and you publish something on server B, the user won’t get notified because it has a websocket connection to server A. If you use something like Redis, the notification will be send to all servers.

And yes, you’ll have to call pubsub.publish() on every change you want to send to subscribers, like when you mutate something. The thing is, GraphQL subscriptions are mostly useful for events and are different than the live queries we are used to in Meteor (with meteor pub/sub). The good news is that @live queries will also come to GraphQL, preventing the need of so many manual publish calls. Read more about the current status here:

I recommend watching the mentioned video.

2 Likes
19

Thank you @jamiter for the explanation. I feel that options.refetchQueries in a mutation does the job of updating the client with less code, so I may not need to use subscriptions.

I like that we no longer need a separate server to use Apollo, which saves a lot of hassle. Beginners could skip Part 2 — The Server: setting up a simple GraphQL server in 5 steps entirely.

Just as an exercise using your package, I’ve been rewriting simple-todos-react to use Apollo (removing withTracker, publish and subscribes and Meteor.calls) and managed to get queries and mutations working.

1 Like
20

Hey @alawi, because you were be interested in how this all got started I though you might like to see this:

The funny thing was that the idea got rejected because the implementation could become to much Meteor specific and fall behind on the default Apollo setup. The fun thing is that it’s ahead of it by supporting subscriptions out-of-the-box and works with most other middleware, because it’s just an Apollo Link.

I plan to keep it ahead of the game :smile:

4 Likes
21

That’s great thanks for sharing @jamiter! I’m surprised the PR didn’t go through. I think a tech fall behind if the team behind it did, as long as the team is active, up to date and believing in their vision, the code will follow.

1 Like
22

@tab00, although fetchQueries might update the app for the current user, I don’t think it will update the page for other users. That’s where subscriptions come into play. Right?

23

Yes, you are right, so it depends on the use case.

For data that needs to be pushed to many users, subscriptions would be required. The graphql-subscriptions documentation makes it seem that the default PubSub is even less scalable than Meteor’s subscriptions. Though it feels quite inconvenient to need to set up (and pay for) Redis / MQTT / Kafka etc.

So if we need subscriptions for a production app that uses Apollo, are there any other options?

24

Well, there is the option to use Mongo for it. You could create a collection where you publish changes to and listen to items getting added on all servers. This is possible, because Meteor is of course able to listen to collection changes. With the right indexes, old messages will automatically be cleaned up. Make this use the PubSubEngine interface, open source it and you’ve made the life of Meteor developers easy again.

We are so spoiled with Meteor, because everything is done for us :laughing:

2 Likes
25

Looks like some work on a Mongo GraphQL Subscription already started here:

Work on it stopped a year ago though, but it’s still interesting as a reference. I like the fact that it’s not Meteor specific, but directly uses the oplog. It doesn’t allow triggering a custom event though. Maybe I can mix it with I had in mind…

1 Like
26

That looks very interesting. Author is @seba in the forums here.

27

Cool, I had totally forgotten about that! But that was made in the early days of Apollo to get a feeling on how it compares against meteor. I haven’t followed Apollo / Graphql development since, so no idea if any of it is still relevant.

28

In my exercise to try to rewrite simple-todos-react to use Apollo via ddp-apollo I haven’t been able to get subscriptions working (using PubSub from graphql-subscriptions) to update the list on the client on insert or removal of a task.

A subscription does works fine for updating the client on changes within individual tasks (e.g. checked, private, text).

Here is my code:

In typeDefs:

  type Subscription {
      tasksChanged: [Task]
  }

In resolvers:

Subscription: {
        tasksChanged: {
            subscribe: () => pubsub.asyncIterator(subChannelTasksChange),
        },
    },

In a mutation:

        taskRemove: (root, args, context) => {
            Tasks.remove(args.taskId);

            pubsub.publish(subChannelTasksChange, {
                tasksChanged: Tasks.find({}, { sort: { createdAt: -1 } }).fetch(),
            });
        },

subscribe call in client component:

componentWillMount() {
    import gql from 'graphql-tag';

    this.props.client.subscribe({
      query: gql`
      subscription tasksChanged {
        tasksChanged {
          _id
          text
          createdAt
          owner
          username
          checked
          private
          }
      }
      `,
    }).subscribe({
      next() {
      },
    });
  }

In the Apollo Client store I can actually see the array of Tasks of the subscription and a new one does appear when I add a task via the UI, and the correct element does disappear when I delete a task from the UI:

ROOT_SUBSCRIPTION
tasksChanged: [Task]
0:▾Task:cLFEuGbTRkQ4BWfMR
1:▾Task:6ALZsoicJGunMBzEF
2:▾Task:cQuds8WPS5SHW45AZ
3:▾Task:DSb7Bt2qqSTN4GdAw
4:▾Task:KXLBapYE8yCLCAhYD
5:▾Task:kvs7BZbv3hS2QMC97
6:▾Task:wdNEnPgbXG4jZMutY
7:▾Task:ABSQo5NPxm8sZBv55
8:▾Task:Ldak6swMS5AuXLCdd
9:▾Task:y4SWjXpZdurKqxX7R

However the list on the UI does not reflect the state of this array, unless I reload the page.

Is the problem in my code or somewhere else?

In case it’s relevant, here is the getTasks query in the client component:

import { graphql, compose } from 'react-apollo';
import { withApollo } from 'react-apollo';

export default withApollo(compose(
  graphql(gql`
  query getTasks {
    tasks {
      _id
      text
      createdAt
      owner
      username
      checked
      private
      }
  }
`,
    {
      props: ({ data: { error, loading, tasks, refetch } }) => {
        if (loading) return { tasksLoading: true };
        if (error) return { hasErrors: true };

        return {
          tasks,
          refetch,
        };
      },
    },
    { name: 'getTasks' }
  ),
)(App));
29

The next() call in subscribe executes on every new change detected.
Adding { data } to the next() call allows access to the new correct data.
Would it be possible to update the UI here?
The problem is that this is a different context to the react component. How can we access the component context in order to modify it?

componentWillMount() {
    import gql from 'graphql-tag';

    this.props.client.subscribe({
      query: gql`
      subscription tasksChanged {
        tasksChanged {
          _id
          text
          createdAt
          owner
          username
          checked
          private
          }
      }
      `,
    }).subscribe({
      next({ data }) {
        //data.tasksChanged is the correct new array of Tasks. Can we update the UI here?
      },
    });
  }
30

It looks like the problem I had with UI not updating after items were added or removed was that arrays don’t have _ids, and Apollo relies on _ids for updating the UI. So instead of publishing an array, I changed the code to publish an object that contains an array and gave the object an _id field. That solved the problem.

1 Like
31

Thanks for diving into this! Maybe something to report at the Apollo Client repo. I’m not sure what the best practices are for such a use case and if the Apollo team is aware of the current implementation implications.

1 Like
32

Thanks to you too for the package. It has given me a chance to try Apollo without as much fuss as I would have needed to go through.

I’m still wondering how to access the React component context from within next({ data }) in subscribe(), in case I want to use the new data to update the component’s state via setState().