Apollo-client: How do you setup client batching with apollo-boost?

[Jinnified]

Hi

I am trying to set up client batching in React with apollo-boost

So I tried this:

import ApolloClient from 'apollo-boost';
import { BatchHttpLink } from 'apollo-link-batch-http';

const client = new ApolloClient({
  link: new BatchHttpLink({ uri: '/graphql', batchInterval: 20 })
});

and this:

import ApolloClient from 'apollo-boost';

const client = new ApolloClient({
  uri: '/graphql',
  batchInterval: 20
});

none of these works. Anyone can shed some light? cheers

versions:
"apollo-boost": "^0.1.4",
"apollo-link-batch-http": "^1.2.1",
react: 16.2

[zengoma]

What errors are being thrown? Your first implementation appears to be correct at a glance.

[Jinnified]

for anyone that seeking the same answer, apollo-boost doesn't seem to support batching yet, i had a look at the source code, it doen not contain support for apollo-link-batch-http, so, if you'd like to use batching, then you have to use apollo-client, rather than boost, please update your offical docs, it recommands apollo-boost everywhere, and looks very confusing to follow.

example code you could use to setup batching at client side:

const batchLink = new BatchHttpLink({
  uri: /graphql,
  batchInterval: 20,
});

const client = new ApolloClient({
  link: batchLink,
  cache: new InMemoryCache(),
  connectToDevTools: process.env.NODE_ENV !== 'production',
});

[zengoma]

@Jinnified Thank you for confirming this. I have been struggling a bit and eventually abandoned Apollo Boost for regular apollo-client. I've also raised a related issue here. It seems I cannot override the default '/graphq' uri with the batchlink either

[peggyrayzis]

Hi! Sorry for the confusion, we do not intend to support batching or custom link configurations in Apollo Boost.

Here's the Apollo Boost migration guide. Do you have any suggestions on how to make it more clear that Apollo Boost doesn't support custom link configurations?

[swernerx]

That's quite unfortunate. I figure batching would be a good default for most people. Is also one of the main selling points to GraphQL.

[wasinsandiego]

@peggyrayzis

Just want to say none of the below is criticism. I think Apollo and all the tools are great. From a usability perspective I thought another point of view may help connect the dots on the confusion. It is still fresh for me and honestly wasn't until this github issue and specifically your post. I can see why the migration guide _should_ come across as clear - and it is - but I can also see why it might be misunderstood. Reading the guide again I can clearly see the parts I must have glazed over.

I totally missed the caveats with boost because of some assumptions on my part. Why I made those assumptions is what may help you make things more clear. Then again, it could just be me that misunderstood things in this way.

I assumed...

• _it is just a wrapper with some pre-configured (preset) things that most folks configure ApolloClient with and that we still had access to the internal ApolloClient._
  This is really about my entry point to apollo boost. I first ran across it in the ApolloClient GH page. There is a quick mention of it in the Install and Usage sections.

From Install:
# installing the preset package npm install apollo-boost graphql-tag graphql --save

From Usage:

"If you load ApolloClient from the apollo-boost package, it will be configured with a few reasonable defaults such as our standard in-memory cache and a link to a GraphQL API at /graphql."

• _it was the preferred way especially for newbies._
  This is totally me and my perception. I ran into references for Apollo Boost all over. In tutorials, articles and the Apollo Client docs and gh readme. Also the migration guide.

• _migration implies "this is what we are doing now guys!"_
  Okay, so this one makes me feel like a total hack. I debated on not sharing this one as it's a little embarrassing, but for the greater good, here goes.

  I honestly did not realize the migration guide was a guide to migrate AWAY from boost. The way it's referenced sometimes in issues - almost as a solution to some problem extending the functionality of boost. I guess this is what threw me off. There is no direct language saying the Apollo Boost Migration is _FROM_ boost _TO_ Apollo Client. Also in my experience migration guides are usually a tool to help the transition from old to new. I'm sure I may be in the minority here but again, just sharing my naive take on all this.

All in all, it's very clear now. But maybe some explicit language in the entry points to the boost documentation would help. Perhaps a little note someplace? Something like this.

NOTE: Apollo Boost is for a quick start with ApolloClient and to get up and running in minutes. As your project moves forward and needs more custom configuration we encourage you to migrate to ApolloClient using this migration guide.

[peterlandry]

For some more context, this just caught me when adding authentication. I'm very new to Apollo Client, so this is actually just part of the learning curve, but coming from the initial setup instructions for React to adding token-based authentication it wasn't clear that the client from apollo-boost was different than the plain client, and link isn't a supported option.

Would changing the boost client import to import ApolloBoostClient from 'apollo-boost' in the docs make this more clear?

[hwillson]

@peterlandry We're going one step further for Apollo Client 3.0 - we're removing Apollo Boost completely. Apollo Client will run with sensible defaults out of the box, which can then be adjusted/removed/configured as needed for more advanced functionality.