The GraphQL Document Fields Needed for Google Sign-In

Let's brainstorm the GraphQL fields we will need to integrate Google OAuth into our app. The first thing we'll do is clear out our schema from part one of the course. We'll go to the type definitions file and remove the schema definitions for the fields we had before. We can also delete the listing folder we've created in the resolvers folder since we'll no longer need the listings resolvers map. We'll create three new GraphQL fields to help with authenticating users with Google OAuth. The first step in our OAuth flow requires us to redirect our user to Google so they can authorize our app and sign in. We'll need to generate the URL that will navigate the user to the Google consent for. We'll construct this URL in our server application and have our React client app be able to retrieve this URL through a query field. This query field is the auth URL field. Once Google sign in provides a code and redirects the user to the slash login path, we'll want to have our React app pass the code to our node server, with which our server will make a request to Google services with the code to retrieve the access token. The login mutation will be the mutation our React client app will fire while passing in the code to make the request to the Google service to retrieve the token and further information for the logged in user. And finally we'll have a logout mutation to have the user request a logout from the client. These are the three GraphQL root level fields we'll need to handle Google OAuth . Let's prepare a GraphQL API type definitions and resolvers with these new fields. In the type definitions file, we'll introduce an auth URL field in our root query object. This field when resolved will return a defined string. Our login mutation will accept a code argument and when resolved will return an instance of the user with which we're going to eventually call the viewer that has been logged in. We'll handle this in the next lesson and for now simply state that it is to return a string. Logout when resolved will also return an instance of the logged in user. For now we'll state that it is to return a string as well. Next let's set up the boilerplate of our res olver functions for the fields we've just created in our schema. We'll have these resolver functions be part of a map that we'll call viewer resolvers. Viewer is the term we'll use to refer to the user desk viewing or using our app and as a result we the term often used to refer to the user that's been logged into our application. We'll create a viewer folder in the resolver's folder which will have an index.ts file. In the index file we'll import the iResolver 's map from Apollo Server Express and set it as the type of the viewer resolver's map we'll create. To simply have our resolver functions set up for the next lesson we'll have each of our resolver functions in this lesson return strings that refer to which field is being quer ied. Query.r.t.u.r.l. mutation.log.in and mutation.log.out. Finally to have our viewer resolver's map in our Apollo Server constructor we must import viewer resolvers in the resolver's index file and place it in the merge function. With our server running we'll open localhost9000/api to launch the GraphQL playground and we can then see that each of our GraphQL fields can now be queried. In the next lesson we'll update these resolver functions to execute the functionality we would want. [ Silence ]