Support Apollo 2.0

[dburles]

Looks like there's API changes in version 2.0 that are incompatible with the latest version of this package.

[xavxyz]

Hey @dburles!

Yes it's not compatible at the moment! Meanwhile a PR is opened, here is how to make the graphql express server created by this package working with Apollo Client 2.0:

import { ApolloClient } from 'apollo-client';
import { ApolloLink } from 'apollo-link';
import { HttpLink } from 'apollo-link-http';
import { InMemoryCache } from 'apollo-cache-inmemory';

// replaces createNetworkInterface
const httpLink = new HttpLink({ uri: Meteor.absoluteUrl('graphql') });

// replaces networkInterface.use([{ applyMiddleware .... 
const authLink = new ApolloLink((operation, forward) => {
  const token = Accounts._storedLoginToken(); // from local storage
  
  operation.setContext(() => ({
    headers: {
      'meteor-login-token': token,
    },
  }));
  
  return forward(operation);
});

const cache = new InMemoryCache();

const client = new ApolloClient({
  link: authLink.concat(httpLink),
  cache,
});

I believe it would be a great time to make this package less "black box": only the authLink would be exported by this package (and this package should become a NPM package?), so the configuration of the client is handled by the developer and not by a black box.

[dburles]

Thanks @xavcz! that sounds great. If the client component can be removed without requiring writing too much boilerplate on the developers side I'm all for it.

[csillag]

As far as I can tell, Apollo Client 2.0 is now out of beta.
So, isn't it time to update this package,too?

[vbelolapotkov]

@xavcz I guess there is a typo above:

import { HttpLink } from 'apollo-http-link';

must be

import { HttpLink } from 'apollo-link-http';

[xavxyz]

Yeah sure. Want to take a shot at making a Meteor Accounts / Apollo integration compatible with Apollo Client 2.0?

[csillag]

No, I kind of just expect this to work out of the box, since these components are all advertised as "ready for production" and such.

If this is not the case, it would be great to clarify this in the relevant README files.

[jaredtmartin]

Thanks a lot, this just saved me. Just to be clear here's the code that works using vbelolapotkov's correction:

import { ApolloClient } from 'apollo-client';
import { ApolloLink } from 'apollo-link';
import { HttpLink } from 'apollo-link-http';
import { InMemoryCache } from 'apollo-cache-inmemory';

// replaces createNetworkInterface
const httpLink = new HttpLink({ uri: Meteor.absoluteUrl('graphql') });

// replaces networkInterface.use([{ applyMiddleware .... 
const authLink = new ApolloLink((operation, forward) => {
  const token = Accounts._storedLoginToken(); // from local storage
  
  operation.setContext(() => ({
    headers: {
      'meteor-login-token': token,
    },
  }));
  
  return forward(operation);
});

const cache = new InMemoryCache();

const client = new ApolloClient({
  link: authLink.concat(httpLink),
  cache,
});
export default client;

[dobesv]

How do I adapt this to work with graphql subscriptions?

[jamiter]

@dobesv, an easy way to use subscriptions right now with Meteor is by using ddp-apollo: https://github.com/Swydo/ddp-apollo

It works with Apollo Client 2 and there is an option to only use it for subscriptions: https://github.com/Swydo/ddp-apollo#using-ddp-only-for-subscriptions

@xavcz Are there plans to make this package work with subscriptions? An option would be to merge the subscription handling part from ddp-apollo into this package and it would work out-of-the-box. Any thoughts? Might want to discuss that in another ticket though 😄

[xavxyz]

Waoooow!! DDPLink & DDPSubscriptionLink, dude you are killing it! 👏

So far my opinion has been, quoting myself from previous comment:

I believe it would be a great time to make this package less "black box": only the authLink would be exported by this package (and this package should become a NPM package?), so the configuration of the client is handled by the developer and not by a black box.

Let's recap what this apollo package is doing at the moment:

1. making GraphQL aware of the Meteor current user from client to server.
2. configure Apollo Client & Apollo Server Express in one line of code.

I love the 1., I find it to be the real interest.

However, I can't stand 2.: it feels to me like before when we were wrapping Node packages in Atmosphere packages and doesn't help people to understand what they are doing with Apollo.

It looks like you, people involved in this thread, would like to keep the value 2.. May I not be the right person anymore to maintain this package?

➡️ I'd love to help for and review any pull request to make this package evolve in the direction the community would like it to go, and transfer the maintainer role.

[jamiter]

Thanks for the quick reply and kind words @xavcz!

Let's focus on making this package compatible with 2.0 first and then move it to npm if possible.

I removed my previous response because it was to much off-topic for this thread

[lorensr]

ddp-apollo looks great, maybe we could deprecate in favor of it?

…

On Fri, Nov 17, 2017 at 3:08 PM Michiel ter Reehorst < ***@***.***> wrote: Thanks for the quick reply and kind words @xavcz <https://github.com/xavcz>! Let's focus on making this package compatible with 2.0 first and then move it to npm if possible. *I removed my previous response because it was to much off-topic for this thread* — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#109 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPVmDrpTG7car6PX_jMXkKtMHiV7MSdks5s3eeqgaJpZM4P-dd7> .