In this section, you’ll learn how you can implement authentication functionality with Apollo to provide signup and login features to your users.
As in the sections before, you’ll set the stage for the login functionality by preparing the React components that are needed for this feature. You’ll start by building the
Let’s quickly understand the structure of this new component, which can have two major states:
inputfields for the user to provide their
password. Notice that
truein this case.
inputfield where users can provide their
name. In this case,
_confirm will be used to implement the mutations that we need to send for the login functionality.
Next you also need to provide the
constants.js file that we use to define the key for the credentials that we’re storing in the browser’s
With that component in place, you can go and add a new route to your
Finally, go ahead and add
Link to the
Header that allows the users to navigate to the
You first retrieve the
authToken from local storage. If the
authToken is not available, the submit-button won’t be rendered any more. That way you make sure only authenticated users can create new links.
You’re also adding a second button to the right of the
Header that users can use to login and logout.
Here is what the ready component looks like:
Perfect, you’re all set now to implement the authentication functionality.
login are two regular GraphQL mutations you can use in the same way as you did with the
createLink mutation from before.
Note that you’re using
compose for the export statement this time since there is more than one mutation that you want to wrap the component with.
Before we take a closer look at the two mutations, go ahead and add the required imports.
Now, let’s understand what’s going in the two mutations you just added to the component.
Both mutations look very similar to the mutations you already saw before. They take a number of arguments returns the
id as well as a
token that you can attach to subsequent requests to authenticate the user (i.e. indicate that a request is made on behalf of that user). You’ll learn in a bit how to do so.
All right, all that’s left to do is call the two mutations inside the code!
The code is pretty straightforward. If the user wants to just login, you’re calling the
loginMutation and pass the provided
password as arguments. Otherwise you’re using the
signupMutation where you additionally pass the user’s
name. After the mutation was performed, you’re storing the returned
localStorage and navigate back to the root route.
You can now create an account by providing a
password. Once you did that, the submit-button will be rendered again:
If you haven’t done so before, go ahead and test the login functionality. Run
yarn start and open
http://localhost:3000/login. Then click the need to create an account?-button and provide some user data for the user you’re creating. Finally, click the create account-button. If all went well, the app navigates back to the root route and your user was created. You can verify that the new user is there by sending the
users query in the dev Playground in the database project.
Now that users are able to login and obtain a token that authenticates them against the GraphQL server, you actually need to make sure that the token gets attached to all requests that are sent to te API.
Since all the API requests are actually created and sent by the
ApolloClient instance in your app, you need to make sure it knows about the user’s token! Luckily, Apollo provides a nice way for authenticating all requests by using the concept of middleware, implemented as an Apollo Link.
This middleware will be invoked every time
ApolloClient sends a request to the server. You can imagine the process of sending a request as a chain of functions that are called. Each function gets passed the GraphQL
operation and another function called
forward needs to be called at the end of the middleware function to pass the
operation to the next middleware function in the chain.
Note: You can read more about Apollo Client’s links here.
That’s it - now all your API requests will be authenticated if a
token is available.
The last thing you’re doing in this chapter is ensure only authenticated users are able to
post new links. Plus, every
Link that’s created by a
post mutation should automatically set the
User who sent the request for its
To implement this functionality, this time you need to make a change on the server-side.
With this change, you’re extracting the
userId from the
Authorization header of the request and use it to directly
connect it with the
Link that’s created. Note that
getUserId will throw an error if the field is not provided or not valid token could be extracted.