DEV Community: mychal

Protected Routes with React Function Components

mychal — Tue, 21 Jan 2020 18:59:12 +0000

Protected routes allow us to ensure only logged in users can access certain parts of our site that may contain private user information. In this post, we'll look at one way of implementing protected routes in React using function components along with react-router. We'll do this first with the useState hook, but in a subsequent post we'll also see how this can be achieved with React's Context API, which is a built-in solution for giving nested child components access to our application's state without the need to pass props all the down our component tree, a practice often referred to as prop drilling.

Getting Started

Let's start by creating a new React project. I'll be using the Create-React-App utility to automatically generate a baseline React app without needing to write any of the boilerplate configuration.

I'm using yarn but you can use npx if you prefer. Let's run the following command in our terminal:

yarn create react-app protected-routes

cd into the newly created protected-routes folder and run yarn start (or npm start) to fire up the dev server. It should open up your browser and display the React logo.

React Router

So now that we have a basic React app, let's create a new directory called components inside the src directory. We'll create 2 components inside this directory: Landing.js and Dashboard.js

protected-routes/src/components/Landing.js

import React from 'react';
import { Link } from 'react-router-dom';

const Landing = () => {
  return (
    <div>
      <h1>Landing</h1>
      <p><Link to='/dashboard'>View Dashboard</Link></p>
      <button>Log In</button>
    </div>
  )
};

export default Landing;

Note, we're using the <Link> component from react-router instead of an anchor tag so that our app won't reload the page when the user clicks the link.

protected-routes/src/components/Dashboard.js

import React from 'react';

const Dashboard = () => {
  return (
    <div>
      <h1>Dashboard</h1>
      <p>Secret Page</p>
      <button>Log Out</button>
    </div>
  )
};

export default Dashboard;

We want to render each of these components depending on the route we're on. To do so, let's install react-router-dom.

yarn add react-router-dom

Open up the App.js file under the src directory and import in the following components from our newly installed package right after the CSS import. Note, I'm giving BrowserRouter the alias Router for brevity. Let's also import the 2 components we created.

protected-routes/src/App.js

import { BrowserRouter as Router, Route } from 'react-router-dom';
import Landing from './components/Landing';
import Dashboard from './components/Dashboard';

We can delete all the stock HTML inside the return statement besides the top level <div> and replace it with our own. We'll use the Route component we just imported to specify which component corresponds to which route. Lastly, we'll need to wrap the <Route> components with our <Router> (aka BrowserRouter) component to tie it all together. Our App.js file should look like this:

import React from 'react';
import logo from './logo.svg';
import './App.css';

import { BrowserRouter as Router, Route } from 'react-router-dom';
import Landing from './components/Landing';
import Dashboard from './components/Dashboard';

function App() {
  return (
    <div className="App">
      <Router>
        <Route exact path='/' component={Landing} />
        <Route exact path='/dashboard' component={Dashboard} />
      </Router>
    </div>
  );
}

export default App;

Now, when we visit localhost:3000 in the browser, we should see a rather plain page with the headline "Landing", a link to /dashboard, and a button for "Log In" (which doesn't do anything yet). Click the link and we'll see that the page now renders the Dashboard component, since our route has now changed to localhost:3000/dashboard

With react-router, there's no need to write additional conditional-rendering logic or utilize state to keep track of which component we should be displaying. Pretty cool, right? 😎. But we still have an issue: our secret Dashboard page is accessible to anyone and everyone. How we can allow only the people who are authorized to view the page navigate to it? First, we'll need to keep track of whether or not our user is logged in our not. Let's see how we can do that using the useState hook.

useState Hook

Prior to the introduction of hooks in version 16.8, the only way to have stateful components in React was through classes. As it's name implies, the useState hook allows us to use state inside a function component. Let's implement useState to keep track of our logged in status.

In App.js, import useState using destructuring in the same line we import React.

protected-routes/src/App.js

import React, { useState } from 'react';

Next, inside of our App function and right before our return block, let's use array destructuring to create a user and setUser variables, which are the first and second elements that useState returns to us, respectively. We'll pass in an initial state of false, to indicate that we are not logged in when we first visit the page.

We'll also create a function called handleLogin which will invoke setUser and flip the user value to true when we click "Log In".

function App() {
  const [user, setUser] = useState(false);

  const handleLogin = e => {
    e.preventDefault();
    setUser(true);
  }

We need to pass this handleLogin function to our Landing component, but it won't work with our current set up since we're passing Landing in as a component prop to Route. We'll need to change the prop from component to render and pass it in as a function that returns our Landing component. Trust me, it sounds more confusing than it is, but in case you want to read more about it, feel free to check out this article.

Our App.js should look like this:

protected-routes/src/App.js

import React, { useState } from 'react';
import './App.css';

import { BrowserRouter as Router, Route } from 'react-router-dom';
import Landing from './components/Landing';
import Dashboard from './components/Dashboard';

function App() {
  const [user, setUser] = useState(false)

  const handleLogin = e => {
    e.preventDefault();
    setUser(true);
  }

  return (
    <div className="App">
      <Router>
        <Route exact path='/' handleLogin={handleLogin} render={props => <Landing {...props} user={user.toString()} handleLogin={handleLogin} />} />
        <Route exact path='/dashboard' component={Dashboard} />
      </Router>
    </div>
  );
}

export default App;

Note, I'm passing in user as a string so we can display it in our Landing component. If you have the React Developer Tools Chrome extension, you can use that to inspect the app's state and make sure everything is working properly.

Let's add an onClick handler to our button in the Landing component using the handleLogin function we just passed down as a prop. Remember to pass in props as an argument, in order to access it inside our component.

protected-routes/src/components/Landing.js

import React from 'react';
import { Link } from 'react-router-dom';

const Landing = props => {
  return (
    <div>
      <h1>Landing</h1>
      <p><Link to='/dashboard'>View Dashboard</Link></p>
      <p>Logged in status: {props.user}</p>
      <button onClick={props.handleLogin}>Log In</button>
    </div>
  )
};

export default Landing;

We should now be able to click the log in button and see our status change to true. This is our state being toggled.

Great, we have our logged in status. Don't worry about wiring up the Log Out button in Dashboard.js for now, we'll do that in the next section.

Now we need a way to allow a user to visit the Dashboard component only if their logged in status is true. How can we enforce that? Enter the protected route component.

Protected Routes

We'll create a new file called ProtectedRoute.js within the components directory. At a high-level, this component will act as a wrapper over react-router's Route component, ultimately returning out the component we wish to render. In other words, we're passing in the component we want to render through an intermediary that abstracts away the need to keep track of state inside our <Dashboard> component. In our case, <ProtectedRoute> becomes a higher-order component. It will be responsible for checking if we're logged in before rendering the <Dashboard> compoent, otherwise it will redirect users to another page (which we'll create shortly).

protected-routes/src/components/ProtectedRoute.js

import React from 'react';
import { Route } from 'react-router-dom';

const ProtectedRoute = ({ component: Component, ...rest }) => {
  return (
    <Route {...rest} render={
      props => <Component {...rest} {...props} />
    } />
  )
}

export default ProtectedRoute;

ProtectedRoute takes in all the same props that we had previously passed into our Route component and returns the very same Route component using the render prop. Let's step through each line individually:

const ProtectedRoute = ({ component: Component, ...rest }) => {

Here we're passing in an object which contains all the props that we'll pass in when we call our <ProtectedRoute> component from App.js. We specify Component so we can reference it later in our render prop. We use rest syntax to pass in our other props without having to know or list them individually.

return (<Route {...rest} render={ props => <Component {...rest} {...props} />

We're simply returning react-router's <Route> component and using its render prop to render the Component we passed in as an argument. We pass in the ...rest props from before in addition to the default props that <Route> provides normally.

We'll see how we can add logic here to check whether or not we're logged in. First let's make sure we haven't broken anything.

Open up App.js, import the ProtectedRoute component, and replace Route with ProtectedRoute where we specify the /dashboard route. Your return should look like this:

protected-routes/src/App.js

  return (
    <div className="App">
      <Router>
        <Route exact path='/' handleLogin={handleLogin} render={
          props => <Landing {...props} user={user.toString()} 
          handleLogin={handleLogin} />} />
        <ProtectedRoute exact path='/dashboard' component={Dashboard} />
      </Router>
    </div>
  );

Fingers crossed, it should work exactly the same. Now let's go back and fix the log out button before we add the logic to our ProtectedRoute.

In App.js, create a handleLogout route that looks identical to the handleLogin route except that it toggles our user state to false. Then pass it down a prop to our ProtectedRoute component. Our full file now looks like this:

protected-routes/src/App.js

import React, { useState } from 'react';
import './App.css';

import { BrowserRouter as Router, Route } from 'react-router-dom';
import Landing from './components/Landing';
import Dashboard from './components/Dashboard';
import ProtectedRoute from './components/ProtectedRoute';

function App() {
  const [user, setUser] = useState(false)

  const handleLogin = e => {
    e.preventDefault();
    setUser(true);
  }

  const handleLogout = e => {
    e.preventDefault();
    setUser(false);
  }

  return (
    <div className="App">
      <Router>
        <Route exact path='/' handleLogin={handleLogin} render={
          props => <Landing {...props} user={user.toString()} handleLogin={handleLogin} />} />
        <ProtectedRoute exact path='/dashboard' handleLogout={handleLogout} component={Dashboard} />
      </Router>
    </div>
  );
}

export default App;

Open up Dashboard.js and add an onClick handler that will trigger our handleLogout function when we click the Log Out button. Remember to pass in a props argument to our Dashboard function where we previously had empty parentheses.

<button onClick={props.handleLogout}>Log Out</button>

Our application should now be able to keep track of our logged in status. You can click each button and use the Back button to see it in action:

Redirect Page

Let's create one more component that we'll redirect users to if they try to access our /dashboard route without first logging in. We'll make this component look a little more interesting than the rest of our black and white app by copying this cool 403 page from codepen by user @anjanas_dh

In the components directory, make a file called Unauthorized.js and add the following markup.

protected-routes/src/Unauthorized.js

import React from 'react';
import { Link } from 'react-router-dom';
import '../Unauthorized.scss';

const Unauthorized = () => {
  return (
    <div className='container'>
      <div class="gandalf">
        <div class="fireball"></div>
        <div class="skirt"></div>
        <div class="sleeves"></div>
        <div class="shoulders">
          <div class="hand left"></div>
          <div class="hand right"></div>
        </div>
        <div class="head">
          <div class="hair"></div>
          <div class="beard"></div>
        </div>
      </div>
      <div class="message">
        <h1>403 - You Shall Not Pass</h1>
        <p>Uh oh, Gandalf is blocking the way!<br />Maybe you have a typo in the url? Or you meant to go to a different location? Like...Hobbiton?</p>
      </div>
      <p><Link to='/'>Back to Home</Link></p>
    </div>
  )
}

export default Unauthorized;

Create a new SCSS file called Unauthorized.scss in the src directory and paste in these styles. I included the link to a pastebin rather than the code itself since the file is 270 lines long.

Since this is a Sass file, it won't work out of the box, but don't fret! We only need to install the node-sass module in order to get us on our wizard way 🧙‍♂️.

yarn add node-sass

Open up App.js and import the Unauthorized component and add it to our list of Route components.

import Unauthorized from './comoponents/Unauthorized';
/* omitting some of the other LOC to save space */
  return (
    <div className="App">
      <Router>
        <Route exact path='/' handleLogin={handleLogin} render={
          props => <Landing {...props} user={user.toString()}
            handleLogin={handleLogin} />} />
        <ProtectedRoute exact path='/dashboard' handleLogout={handleLogout} component={Dashboard} />
        <Route exact path='/unauthorized' component={Unauthorized} />
      </Router>
    </div>
  );
/* omitting some of the other LOC to save space */

If all went according to plan, you should see the following page when you navigate to '/unauthorized'

Protecting the Route

Ok, now we're in the home stretch! Let's add in the logic to ensure we're logged in before we can view the Dashboard component. First, let's pass in our user state as a prop to our ProtectedRoute in App.js.

protected-routes/src/App.js

<ProtectedRoute exact path='/dashboard' user={user} handleLogout={handleLogout} component={Dashboard} />

Jump back into ProtectedRoute.js and let's add a conditional that checks if our user status is set to true, in which case we'll render the Component, otherwise, redirect to our /unauthorized route. Therefore we'll need to import the <Redirect> component from react-router as well. Here's what the final ProtectedRoute component should look like:

import React from 'react';
import { Route, Redirect } from 'react-router-dom';

const ProtectedRoute = ({ component: Component, user, ...rest }) => {
  return (
    <Route {...rest} render={
      props => {
        if (user) {
          return <Component {...rest} {...props} />
        } else {
          return <Redirect to={
            {
              pathname: '/unauthorized',
              state: {
                from: props.location
              }
            }
          } />
        }
      }
    } />
  )
}

export default ProtectedRoute;

Note, we're now specifying user as one of the props we're passing into our ProtectedRoute component since we're referencing it a little later on in our if statement that checks if we've "logged in" or not.

If user evaluates to true, then we'll render our component as normal
However, if it's set to false, we'll use the <Redirect> component from react-router to redirect the user to '/unauthorized'.

Alright, now the moment of truth. Let's try accessing the "View Dashboard" link without first "logging in". We should be greeted by Gandalf the Grey.

Now let's click the log in button to simulate authentication. Our status changes to true and when we click on the "View Dashboard" link, our app should now render the Dashboard component. If we click "Log Out", we'll be immediately booted to the Unauthorized page.

Summary

We got a glimpse of how we can protect private pages with react-router and our <ProtectedRoute> higher-order component. We utilized the useState hook to give our function components access to state, which we passed down as props to child components. As mentioned at the onset, we'll take a look in a future post at how we can use the Context API to avoid having to prop drill.

If you made it to the end, thanks for reading. I appreciate any comments or suggestions, so feel free to leave them below. As always, happy hacking!

A Brief Tour of GraphQL

mychal — Sun, 12 Jan 2020 23:45:12 +0000

What is GraphQL?

GraphQL is a query language initially developed at Facebook before being open sourced in 2015. It was created to solve some of the issues associated with RESTful architecture and provide finer-grain control over what data is being requested and returned.

In addition, GraphQL is agnostic about the sources of data, so it can facilitate the retrieval of data from various APIs or even expose your APIs directly.

We'll discuss the trade-offs of GraphQL and create a simple project so we can familiarize ourselves with the syntax. Let's get started!

Comparison with REST

One of the easiest ways to understand the power of GraphQL is to compare it to REST. If you're also new to REST, you can check out this resource to learn more, but at a high-level just know that REST is an architectural paradigm that provides guidelines of how resources should be accessed and served up to clients. It is immensely popular for building web applications.

REST's popularity is not without merit, it certainly has proved itself to be more than capable of powering some of the largest sites on the internet. However, as the web continues to evolve, spurred by the hockey-stick growth of mobile users, the limitations of REST are beginning to manifest and developers are looking for ways to optimize.

Issue 1: Too many routes

Consider the following...Suppose we want to fetch a user's post and the comments associated with it:

In a RESTful Node.js application, we might set up a route like the one below:

const express = require('express');
const router = express.Router();
// Middleware that will query our database and pass data along to our route handler
const dbController = require('../controllers/db');

// GET postById route
router.get('/post/:id', dbController.getPostById, (req, res) => {
  res.json({
    confirmation: 'success',
    postId: res.locals.postId,
    postBody: res.locals.body,
    userId: res.locals.userId,
    profilePicURL: res.locals.profilePicURL,
    timestamp: res.locals.timestamp 
});

In order to get the comments, we'll need to hit another endpoint:

// GET commentById route
router.get('/comment/:postId', dbController.getCommentsByPostId, (req, res) => {
  res.json({
    confirmation: 'success',
    comments: res.locals.comments
  });
})

Now say we want to add a comment of our own, we'd need to add a POST route. To edit a post, we'll need a separate route to handle PUT requests. Ditto for updating any existing comments...You can see how for every interaction we have with our app, we'd need to set up a corresponding route.

This works, but can become cumbersome as our list of routes continues to grow. In addition, if the front end team wants to change the data they're displaying, they'll have to ask the back end team to change the API.

GraphQL, on the other hand, only has one URL endpoint (conventionally something like '/graphql'). The logic for what happens is built into the resolver functions (more on those later).

One Endpoint to Rule Them All

To handle CRUD in REST, we need a separate endpoint and functions to handle what happens when we hit that end point. In GraphQL, all queries and mutations hit one URL and the functions to resolve those requests are handled individually.

Issue 2: API versioning

Another issue a company may face is when they want to make changes to their public facing API, they run the risk of breaking applications that are expecting the data to be returned in a certain way. The workaround for this involves creating multiple versions of an API, hence why you'll see some APIs labeled v1, v2, v3, etc. This adds some complexity and overhead for the team maintaining the API.

With GraphQL, more features can be added without worrying about breaking changes since all existing queries will still be resolved as expected and any new changes can still be accessed by clients wishing to implement them.

Issue 3: Over-fetching/Under-fetching

Additionally, if you only need one piece of data that an existing route provides, there's no way in REST to only fetch the data you want without creating another custom route. You're getting the entire response object and only utilizing pieces of it. This problem is known as over-fetching and means you're paying to send over data you don't need which in turn sacrifices speed.

The flip-side to this is known as under-fetching, which happens when a route doesn't provide all the data that's needed to render by the client so another trip to the server is required. Sort of like in our post example above. Multiple round-trips to the server are problematic because again it introduces unnecessary latency which results in a worse user experience.

GraphQL solves this by letting the client specify exactly what data it needs and the server can then wrangle this data from any source and return it all in one response. Pretty cool, huh?

Disadvantages

Caching
While GraphQL has many benefits, it does also come with some trade-offs. For example, caching is not as straightforward with GraphQL as it is in REST, since its queries lack some type of built-in, globally unique identifier like a URL to delineate which resources are being accessed frequently. It also doesn't play as well with HTTP caching, since many implementations of GraphQL in the wild only rely on one type of request (typically a POST).

Rate Limiting
Another issue to consider is rate limiting. For public-facing APIs, companies will often limit the number of requests clients can make to a particular resource for a given period of time. This is easier in REST since each endpoint can be limited separately. With a GraphQL API, a company may need come up with their own rate limiting calculations. These can quickly grow in complexity as it can be difficult to predict if a GraphQL request will result in a costly operation or not since it's up to the client to specify what data they need.

Performance
While GraphQL's flexibility is one of its main selling points, it can also result in performance issues. Deeply nested queries can take time to resolve, which could add unexpected latency for end users. This is something that needs to be weighed against alternative approaches, such as making multiple round-trips to the server, which adds more network latency but may reduce overall server workload.

A Quick Example

So now we know some of the pros and cons of GraphQL, let's roll up our sleeves and try it out. We'll be building a very simple book library and write some queries to look up some books.

First, let's create a project directory and cd into it. We'll use npm to scaffold a Node.js project (the -y flag means to accept all the defaults). We'll also install three packages, express, graphql, and express-graphql, to set up our GraphQL service.

mkdir graphql-example
cd graphql-example
npm init -y
npm i -S express graphql express-graphql

Let's create an index.js file where will write our server logic. First we'll require in express and bootstrap our app. Note, our service won't work until we define a route handler and import our schema, both of which we'll do shortly.

graphql-example/index.js

const express = require('express');
const app = express();

const { buildSchema } = require('graphql');
const graphqlExpress = require('express-graphql');

// Initialize an array where we'll store our books
const books = [];

// We'll insert our /graphql route handler here in just a second. For now, our server won't do anything interesting.

// Our server will listen on port 4000;
const PORT = 4000;
app.listen(PORT, () => {
  console.log(`Listening on port ${PORT}`);
});

I mentioned our app isn't fully functional yet. Let's fix that. Create another file called bookSchema.js. In it we'll export a string listing out our types. But first, we need to discuss how to write GraphQL schemas.

Types

In GraphQL, we define types as any object we can fetch from our service. For our library app, we may define a book type like so:

example book type definition

type Book {
  title: String!
  author: String!
}

There are three different ways to represent a GraphQL schema, but for our purposes we'll stick to the one that's easiest to read/write: the Schema Definition Language (or SDL). The snippet above is an example of SDL. If you're interested in the other ways, check out this article.

There are two special types in GraphQL: query and mutation. Every GraphQL service will have a query type, because GraphQL needs an entry point for each request it receives. Mutations, like their name suggests, deal with how we change (or mutate) our data.

So in our newly created bookSchema file, let's add the following code:

graphql-example/bookSchema.js

module.exports.types = `
type Query {
  greeting: String
  books: [Book]
}

type Book {
  id: Int!
  title: String!
  author: String!
}
`

Here we just defined Query, our root object, and also a Book object. Query has two fields, greeting which returns a string, and books which will return a list of Book objects. Each Book will itself contain three fields that are all required (i.e. they can't return null) as denoted by the bang.

Resolvers

So GraphQL types tell us what our data will look like and what kinds of queries our client can send. How we actually return that data is handled by specific functions, known as resolvers, that correspond to each type. Their job is to resolve queries and mutations with the values that they return.

Let's jump back into our index.js file and require in our types and write some resolvers.

Use destructuring to require in our types string from bookSchema.js
Next, right below where we declared the empty books array, declare a constant called resolvers which will be an object containing two keys, each with their own function.
Then create a route handler for our '/graphql' endpoint where our previous comments had specified. Here's where we'll use the graphqlExpress package.
Finally, create a variable called schema and call the buildSchema method that the graphql library provides, passing in our types string that we just imported.

Our index file should now look like this:

graphql-example/index.js

const express = require('express');
const app = express();

const { buildSchema } = require('graphql');
const graphqlExpress = require('express-graphql');
const { types } = require('./bookSchema');

// Initialize an array where we'll store our books
const books = [];
const resolvers = {
  greeting: () => 'Hello world!',
  books: () => books
}

const schema = buildSchema(types);
app.use('/graphql', 
  graphqlExpress({
    schema,
    rootValue: resolvers,
    graphiql: true
  })
);

// Our server will listen on port 4000;
const PORT = 4000;
app.listen(PORT, () => {
  console.log(`Listening on port ${PORT}`);
});

Now it's finally time to write our first GraphQL query. Fire up the server by executing the node index.js command in the terminal. If there are no bugs, it should log:

Listening on port 4000

Now open up your browser and navigate to localhost:4000/graphql. We should see the GraphiQL IDE immediately load.

Delete all the commented text and write a query to retrieve our greeting (see screenshot below). Hit the play button (or ctrl + enter) and we should get back a response:

Awesome! We've just written our first GraphQL query! This example still lacks functionality, so let's go ahead and add our a Mutation type in order to interact with our mock library API.

Open up our bookSchema.js file and append the following string just after the type Book block:

graphql-example/bookSchema.js

type Mutation {
  addBook ( id: Int!, title: String!, author: String! ): [Book]
}

Here we're defining our root Mutation and giving it an addBook field, which has three required parameters and returns an array of Book objects.

In order to give our addBook mutation some functionality, we'll need to create a corresponding resolver function. Head back to index.js and update our resolvers object as follows:

const resolvers = {
  greeting: () => 'Hello world!',
  books: () => books,
  addBook: args => {
    const newBook = {
      id: args.id,
      title: args.title,
      author: args.author
    };

    books.push(newBook);
    return books;
  }
}

Ok, so here we have our first resolver that takes in an argument, creatively called args. In reality, all resolver functions actually receive four arguments as inputs. They are typically called:

parent/root - The result of the previous (or parent) resolvers execution. Since we can nest queries in GraphQL (like nesting objects), the parent argument gives us access to what the previous resolver function returned.
args - These are the arguments provided to the field in the GraphQL query. In our case, args will be the id, title, and author of the new book we wish to add.
context - An object that gets passed through the resolver chain that each resolver can write to and read from (basically a means for resolvers to communicate and share information).
info A value which holds field-specific information relevant to the current query as well as the schema details. Read more about it here.

However, since our two previous resolvers (greeting and books) were fairly trivial and didn't need access to anything the four arguments provide we simply omitted them.

Let's test out our addBook functionality. Spin up the server again and open the browser. Then execute the following mutation:

Pretty cool, huh? We just pushed a new book to our previously empty books array. We can verify this with our books query by executing the following in GraphiQL:

{
  books {
    id
    title
    author
  }
}

If run another addBook mutation, this time with a different id, title, and author, and execute the books query again, we should see our books array grow to two objects.

Let's add one more piece of functionality before wrapping things up. Head back to the bookSchema.js file and add a field called deleteBook within the Mutation block. Our file should now look like this:

graphql-example/bookSchema.js

module.exports.types = `
type Query {
  greeting: String
  books: [Book]
}

type Book {
  id: Int!
  title: String!
  author: String!
}

type Mutation {
  addBook ( id: Int!, title: String!, author: String! ): [Book]
  deleteBook ( id: Int, title: String ): [Book]
}
`

And append the following function definition to the resolvers object:

graphql-example/index.js

  deleteBook: args => {
    if (args.id) {
      books.forEach( (book, index) => {
        if (book.id === args.id) {
          books.splice(index, 1);
        }
      });
    } 
    if (args.title) {
      books.forEach( (book, index) => {
        if (book.title === args.title) {
          books.splice(index, 1);
        } 
      });
    } 
    return books;
  }

When we call the deleteBook mutation, we'll pass it either the id or title of the book we want to remove. Our deleteBook resolver will loop through our entire array and find the object whose property matches the argument and splice it out of the array, subsequently returning the modified books array.

Here is what both files should ultimately look like:

graphql-example/index.js

const express = require('express');
const app = express();

const { buildSchema } = require('graphql');
const graphqlExpress = require('express-graphql');
const { types } = require('./bookSchema');

// Initialize an array where we'll store our books
const books = [];
const resolvers = {
  greeting: () => 'Hello world!',
  books: () => books,
  addBook: args => {
    const newBook = {
      id: args.id,
      title: args.title,
      author: args.author
    };

    books.push(newBook);
    return books;
  },
  deleteBook: args => {
    if (args.id) {
      books.forEach( (book, index) => {
        if (book.id === args.id) {
          books.splice(index,1);
        }
      });
    } 
    if (args.title) {
      books.forEach( (book, index) => {
        if (book.title === args.title) {
          books.splice(index, 1);
        } 
      });
    } 
    return books;
  }

}

const schema = buildSchema(types);
app.use('/graphql',
  graphqlExpress({
    schema,
    rootValue: resolvers,
    graphiql: true
  })
);

// Our server will listen on port 4000;
const PORT = 4000;
app.listen(PORT, () => {
  console.log(`Listening on port ${PORT}`);
});

graphql-example/bookSchema.js

module.exports.types = `
type Query {
  greeting: String
  books: [Book]
}

type Book {
  id: Int!
  title: String!
  author: String!
}

type Mutation {
  addBook ( id: Int!, title: String!, author: String! ): [Book]
  deleteBook ( id: Int, title: String ): [Book]
}
`

Finally, we'll test drive it in GraphiQL. Restart the server and run the addBook mutation twice, changing the values each time. Verify there are two different books in our array with the books query.

Now we can call deleteBook and pass in either the title or id of one the books. With any luck, the matching book should be removed from our array, leaving the other book as the lone object.

If it works, congrats! We're now starting to see how GraphQL can be implemented where we typically might build out a RESTful API.

As I previously mentioned, one of the benefits of using GraphQL is you can specify exactly what data you want to receive back. So for example, if we only needed the title to be returned and didn't care about the id or author, all we'd need to do is adjust our query/mutation from the client and 🔥BOOM🔥 we get back our data in exactly the shape we want.

GraphQL gives us fine-grain control over the shape of our data without having to change the back end API

Compare that to REST, where we'd have to also adjust our back end API for every change (and run the risk of breaking some downstream apps in the process). Pretty powerful stuff!

Recap

With our add and delete functions working, we're halfway to a basic CRUD app. For additional practice, try adding functionality to getBookById and updateBook on your own. I should also note that our books are only being saved in-memory so they'll be erased each time we restart the server. In order to make changes persistent, we'd need to hook up our app to a database, which is beyond the scope of this introduction, but something I recommend trying to implement as well.

So there you have it, a brief tour of GraphQL. Ostensibly, there is much more to GraphQL than we're able to touch on here, but hopefully this demo was enough to spark your interest.

If you want to continue learning about GraphQL, you're in luck. The community has created some phenomenal resources. Here are just a few that I recommend:

Leave a comment below if you have any questions or thoughts. Happy hacking!