We chose Apollo Client two years ago for a React project. The package we used originally was apollo-boost, later in order to support upload, we moved to apollo-boost-upload, which is just apollo-boost + apollo-link-upload, nothing needs to be changed in our original code. And we also used react-apollo in order to use <code>&lt;Query&gt;</code> and <code>&lt;Mutation&gt;</code> components.<figure class="image"><img src="https://images.unsplash.com/photo-1581822261290-991b38693d1b?ixlib=rb-1.2.1&amp;q=80&amp;fm=jpg&amp;crop=entropy&amp;cs=tinysrgb&amp;w=1080&amp;fit=max&amp;ixid=eyJhcHBfaWQiOjE1NDAxMH0"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@sushioutlaw?utm_source=DNX&amp;utm_medium=referral">Brian McGowan</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure>Since the Apollo-Boost project is now retired, and React-Apollo has been deprecated, it's time to migrate to Apollo Clients 3.0.Apollo Clients package includes both React hooks and Graphql request handling, so we don't need to do install separate packages, like Apollo-Boost and React-Apollo. However, Apollo Client 3.0 is mainly focusing on Hooks when being used in the React project. And our React codebase is still mainly using the Class component, which would take some time to rewrite using Hook. So we decided to migrate to Apollo Client 3.0 without using Hook, and then granularly rewrite the code to using Hook.There is not too much documentation about how to use Apollo Client 3.0 with React Class Component. But there is the way.Please keep in mind:<blockquote>In order to use Apollo Client 3.0 with React Class Component, we have to use some depreacted API, like React Components and HOC</blockquote><h3>ApolloClient Constructor</h3>First of all, remove ‘Apollo-Boost’, in our case, it's “Apollo-Boost-Upload”.<pre><code class="language-javascript" id="Akh2Yq14p">// import ApolloClient from "apollo-boost-upload";	
// import { ApolloProvider } from 'react-apollo';
import { ApolloClient, ApolloProvider, InMemoryCache } from "@apollo/client";</code></pre>If you don't use Authorization or Upload, then the main change would be manually setting up the cache. Here we will explain all of those changes.<h4>Authorization Header</h4>With Apollo-Boost, we can pass the authorization token in the ‘headers’ option like this:<pre><code class="language-javascript" id="Y5DLTFNEi"> const client = new ApolloClient({
 	headers: {
 	Authorization: token,
 },</code></pre>But in @apollo/client, we have to use apollo- link<pre><code class="language-javascript" id="MtNC6MBFo">import { ApolloLink } from "apollo-link";

const authLink = new ApolloLink((operation, forward) =&gt; {
 // Use the setContext method to set the HTTP headers.
 operation.setContext({
 headers: {
 authorization: token ? `Bearer ${token}` : "",
 },
 });

 // Call the next link in the middleware chain.
 return forward(operation);
});</code></pre><h4>Enable Upload</h4>By default, Apollo Client does not allow FileList, File, Blob, or ReactNativeFile instances within query or mutation variables and sends GraphQL multipart requests. So we need apollo-upload-client to support this.<pre><code class="language-javascript" id="QjoD2DUQw">import { createUploadLink } from "apollo-upload-client";

const uploadLink = new createUploadLink ({ uri: YOURAPIURI});</code></pre>Note that, when we use apollo-boost, we pass in <code>uri</code>. But when we use @apollo/client, we can pass in <code>link</code> or <code>uri</code>. The difference between <code>link</code> and <code>uri</code> is that the former allows us to compose actions around data, i.e., we can chain different links together to implement complex data handling logic. See the diagram below:&nbsp;<figure class="image"><img src="https://images.deniapps.com/ymiowjj-1.png"><figcaption>Chainable Apollo Link- Photo from <a target="_blank" rel="noopener noreferrer" href="https://www.apollographql.com/">ApolloGraphql</a></figcaption></figure>In our case, we could chain <code>authLink</code> and <code>uploadLink</code>, like below:<pre><code class="language-javascript" id="4rjIljVeF">const link = ApolloLink.from([
 authLink,
 uploadLink
]);

const client = new ApolloClient({
 // uri: nccihAPI,
 link: link,
 cache: cache,
 typeDefs,
 resolvers,
});</code></pre><h4>Cache</h4>You probably see the cache in the above ApolloClient constructor. When we use apollo-booster, it integrates InMemoryCache for us, so there is no need to pass in the cache option. But when use @apollo/client, we have to manually create this. Below is how to create a cache using <code>InMemoryCache</code> with some local states:<pre><code class="language-javascript" id="qkjsYettp">const localStateValue = {
 userId,
 displayName,
};

const cache = new InMemoryCache({
 typePolicies: {
 Query: {
 fields: {
 currentUser: {
 read() {
 return localStateVar();
 },
 },
 },
 },
 },
});

const localStateVar = cache.makeVar(localStateValue);</code></pre><h3>ApolloProvider</h3>To migrate to ApolloClient 3, we only need to import ApolloPrivder from "@apollo/client" instead of “react-apollo”. We still use <code>ApolloProvider</code> like before in the top component, in our case, App.js<pre><code class="language-javascript" id="AhigcwMxn">&lt;ApolloProvider client={this.state.client}&gt;
	&lt;div className="App container"&gt;
 	&lt;Switch&gt;
 	&lt;Route path="/preview/:pageType/:pageId" component={Preview} /&gt;
 	&lt;Route path="/*" component={Dashboard} /&gt;
 &lt;/Switch&gt;
 &lt;/div&gt;
&lt;/ApolloProvider&gt;</code></pre><h3>Query &amp; Mutation</h3>Since we are still using the Class component, we cannot take an advantage of Hook (<code>useQuery</code> and <code>useMutation</code>.) In ApolloClient 3, we can continue to use <code>&lt;Query&gt;</code> and <code>&lt;Mutation&gt;</code> component, and it works pretty much the same way as that in react-apollo. We only need to import them from @apollo/client package, like:<pre><code class="language-javascript" id="fwQV-mBDj">import { Query, Mutation } from "@apollo/client/react/components";</code></pre><h3>Manually firing a Query</h3>When use Query component, Apollo Client automatically fires off our query, but sometimes, we wanted to manually fire a query until the user performs an action. In that scenario, we need to be able to access Apollo Client in the child component. When use react-apollo, we can use ‘<code>withApollo</code>’, a high order function, wrapping the child component to make <code>this.props.client</code> available in the child component, like this:<pre><code class="language-javascript" id="sbYRhxwHj">import { withApollo } from "react-apollo";

class CustomPageList extends Component {
	handleDelete = async (e, item, customPageList) =&gt; {
 	const { data } = await this.props.client.query({
 		query: GET_IsPageUsedAsHighlightFeatured,
 		fetchPolicy: "no-cache",
 		variables: { uuid: item.uuid },
 	});
 });
}
export default withApollo(CustomPageList);
</code></pre>We could still use HOC to pass in Apollo Client, but it becomes a little bit complexly. To do that, we should use ApolloConsumer, like this:<pre><code class="language-javascript" id="aF14BFosd">import { ApolloConsumer } from "@apollo/client";

const WithApolloCustomPageList = (props) =&gt; (
 &lt;ApolloConsumer&gt;
 {(client) =&gt; {
 return &lt;CustomPageList {...props} client={client} /&gt;;
 }}
 &lt;/ApolloConsumer&gt;
);

export default WithApolloCustomPageList; </code></pre>That's it!&nbsp;

Apollo Client 3.0 includes some breaking changes, but since the Apollo Boost project is now retired, and React-Apollo has been deprecated, it's time to migrate. But Apollo Client 3.0 is mainly focusing on Hooks when being used in the React project. If your React project is not Hook ready yet, you may be wondering it's possible to use Apollo Client 3 with React Class Components or not. In short, the answer is YES.

Migrating to Apollo Client 3.0

Our Apollo Server is running on AWS Lambda using Serverless Framework, and then it's accessed thru AWS API Gateway using Cognito User Pool as an authorizer.&nbsp;<blockquote>More information about Amazon Cognito User Pools can be found in <a target="_blank" rel="noopener noreferrer" href="https://deniapps.com/blog/how-tokens-work-in-amazon-cognito-user-pools">this article</a>.</blockquote><figure class="image"><img src="https://images.unsplash.com/photo-1600695268275-1a6468700bd5?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=MXwxNTQwMTB8MHwxfHJhbmRvbXx8fHx8fHx8&amp;ixlib=rb-1.2.1&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@markusspiske?utm_source=DNX&amp;utm_medium=referral">Markus Spiske</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure>Our frontend (CMS) is running on top of Create React App with Apollo Client.On the localhost, we use serverless offline, so there is not API Gateway, Cognito User Pool, and Lambda in between the Apollo Client and Apollo Server.We received a lot of complaints from the CMS users that they got the “Failed to Fetch” error a few times almost every day when they were working on the website. &nbsp;When that happened, the CMS cannot communicate to the API server. With console log enable, we saw the information like below:<blockquote>[Network error]: TypeError: Failed to fetch &nbsp;&nbsp;Access to fetch at ‘https://API-URI/graphql’ from origin ‘https://CMS-URL’ has been blocked by CORS policy: "No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request's mode to ‘no-cors’ to fetch the resource with CORS disabled.&nbsp;&nbsp;&nbsp;Failed to load resource: https://API-URL/graphql:1 net:ERR_FAILED&nbsp;</blockquote>The hard part to solve this issue is that:<ol><li>There wasn't useful information that could be found in the AWS Cloudwatch</li><li>We could not reproduce it on the local, or on production (with brief test)</li></ol>After spending a lot of time checking the network connection (the CMS can only access via VPN), API Gateway, Lamba, RDS proxy, MySQL database, etc., everything that is different between Localhost and Production, we still could not find the clues.&nbsp;<blockquote>We were pretty sure that the CORS is enabled on Apollo Server. &nbsp;Somehow the server's response does not send the No "Access-Control-Allow-Origin’ header, and the client does not set the request's mode to ‘no-cors’, &nbsp;so the browser throws this error.</blockquote><blockquote>More informatio about CORS error could be found in <a target="_blank" rel="noopener noreferrer" href="https://deniapps.com/blog/false-alarm-of-cors-error">this article</a></blockquote>So, how about eliminating the CORS log first? We need to see the real error log.&nbsp;<blockquote>All debugging starts from the log - Adam C.&nbsp;</blockquote>We took a second look at the API Gateway and found that we should manually add the “Access-Control-Allow-Origin” header to 4xx and 5xx response, otherwise, this header will be missing from the response, and then the real 4xx and 5xx error will be hidden, because the browser will complain CORS errors as shown above.After adding this header with the value “*”, we got the new error report from our CMS users. As expected, we saw the real error message:<blockquote>Failed to load resource: the server responded with a status of 401 ()&nbsp;&nbsp;[Network error]: ServerError: Response not successful: Reveived status code 401</blockquote>After finding the root of failure, the fixing became much more targetable. We quickly figured out that it's related to the Cognito user pool, which we use as an authorizer. The AccessToken and IDToken are set with a short expiration time of one hour, so if the user is on the website for more than one hour, &nbsp;he/she will use pass an expired token for API call, therefore, the 401 unauthorized error will be received. Also, after refreshing the page, everything is back to normal, that's because the lifetime of refreshToken is one day, and Amplify will auto-refresh the AccessToken and IDToken as long as the refreshToken is not expired.&nbsp;So the solution is clear that we just need to refresh the AccessToken/IDToken when they are expired, but we need to do this in the background without refreshing the page, otherwise, the user's unsaved work will get lost. &nbsp;We use Amplify React UI Component to handle user login. When the login is successful or the user is already logged in, the ID token is passed to Apollo authLink as below:<pre><code class="language-javascript" id="80kA0Le8f">Auth.currentAuthenticatedUser().then(async (user) =&gt; {
 const token = user.signInUserSession.idToken.jwtToken;
 const authLink = new ApolloLink((operation, forward) =&gt; {
 // Use the setContext method to set the HTTP headers.
 operation.setContext({
 headers: {
 authorization: token ? `Bearer ${token}` : ""
 }
 });

 // Call the next link in the middleware chain.
 return forward(operation);
 });
});</code></pre>The logic above is implemented in the App.js, which is the parent component of all, and it's only run once at the componentDidMount lifecycle, so without refreshing the page, the token is never changed. But as we learned above, when the token is expired, the 401 unauthorized error is received. The Apollo Client allows us to check for a certain failure condition or error code, and retry the request if rectifying the error is possible. Below is what we came up using the ErrorLink: (If you are not familiar with Apollo Link, check it out <a target="_blank" rel="noopener noreferrer" href="https://www.apollographql.com/docs/react/api/link/introduction/">here</a>)<pre><code class="language-javascript" id="hAPivEyJR">const handlErrorLink = onError(
 ({ graphQLErrors, networkError, operation, forward }) =&gt; {
 if (graphQLErrors)
 graphQLErrors.forEach(({ message, locations, path }) =&gt;
 console.log(
 `[GraphQL error]: Message: ${message}, Location: ${locations}, Path: ${path}`
 )
 );
 if (networkError) {
 if (String(networkError).match(/Received status code 401/i)) {
 return fromPromise(
 Auth.currentAuthenticatedUser()
 .then(async (user) =&gt; {
 return user.signInUserSession.idToken.jwtToken;
 })
 .catch((error) =&gt; {
 console.log("refresh token failed: ", error);
 // Handle token refresh errors e.g clear stored tokens, redirect to login, ...
 return;
 })
 )
 .filter((value) =&gt; {
 return Boolean(value);
 })
 .flatMap((token) =&gt; {
 const oldHeaders = operation.getContext().headers;
 // modify the operation context with a new token
 operation.setContext({
 headers: {
 ...oldHeaders,
 authorization: `Bearer ${token}`,
 },
 });
 return forward(operation);
 });
 }

 console.log(`[Network error]: ${networkError}`);
 }
 }
);</code></pre>Note the in our case, the 401 unauthorized is captured in networkError, and the error string contains “<code>Received status code 401”</code> which we used to filter, and <code>Auth.currentAuthenticatedUse,</code> the function provided by ‘Amplify’ is asynchronous, so we have to use <code>fromPromise,</code> the function provided by ‘apollo-link’ to token from a Promise object, and then replace the old header in operation context, finally forward the operation to retry.After this, we had the annoying ‘failed to fetch’ error fixed. :-)&nbsp;

In this article, we learned how to fix the 'failed to fetch' error from API-Gateway in our AWS Lambda Serverless Framework. The root cause is ended up to be the expired AWS Cognito Access/ID tokens. We were able to fix this by utilizing the Apollo Error Link to replace the old token with the refreshed one, and then retry the request.

All Posts In Apollo Client