Full Stack GraphQL Applications With React, Node.js, and Neo4j (MEAP V09) (William Lyon)（Z-Library）

📄 File Format: PDF

💾 File Size: 20.5 MB

📖 Read Online ⬇️ Download

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1

(This page has no text content)

📄 Page 2

MEAP Edition Manning Early Access Program Fullstack GraphQL Applications With React, Node.js, and Neo4j Version 9 Copyright 2022 Manning Publications For more information on this and other Manning titles go to manning.com ©Manning Publications Co. To comment go to liveBook https://livebook.manning.com/#!/book/fullstack-graphql-applications/discussion

📄 Page 3

welcome Dear Reader – Thank you for purchasing the MEAP for Full Stack GraphQL Applications With React, Node.js, and Neo4j! This book is intended for developers interested in building fullstack applications with GraphQL. The successful reader will have some basic familiarity with Node.js and a basic understanding of client-side JavaScript, but most importantly will have a motivation for understanding how to build GraphQL services and applications leveraging GraphQL. The goal of this book is to demonstrate how GraphQL, React, Apollo, and Neo4j Database can be used together to build complex, data intensive fullstack applications. You may be wondering why we've chosen this specific combination of technologies. As you read through the book I hope you'll realize the developer productivity, performance, and intuitive benefits of using a graph data model throughout the stack, from the database to the API, and all the way through frontend client data fetching code. The book is divided into three parts, which together show how to build a fullstack business reviews application with features such as search and personalized recommendations. The first part focuses on server-side GraphQL, specifically showing how to design a GraphQL schema from business requirements, then using that GraphQL schema with the Neo4j graph database, adding not just simple data fetching, but also implementing custom logic using graph database traversals. We start with an overview of both GraphQL and Neo4j, then show how to combine them using the GraphQL integration for Neo4j known as neo4j-graphql.js Next, we explore building a frontend for our application, focusing on using React and GraphQL integrations for React such as Apollo Client and urql. We focus on best practices for state management, caching, and using React hooks with GraphQL data fetching. Then in the final part we cement the functionality of our application with more real-world concerns, such as adding authorization, exploring serverless deployment options, streaming data with GraphQL subscriptions, and more advanced GraphQL considerations such as rate limiting and working with Cloud databases. You can find all the relevant code and exercise solutions in the book's GitHub page: github.com/johnymontana/fullstack-graphql-book and please feel free to reach out via the liveBook's Discussion Forum with any questions, feedback, or discussion about the book and working with GRANDstack. Cheers, —William Lyon ©Manning Publications Co. To comment go to liveBook https://livebook.manning.com/#!/book/fullstack-graphql-applications/discussion

📄 Page 4

brief contents PART 1: GETTING STARTED WITH FULLSTACK GRAPHQL 1 What Is Full Stack GraphQL? 2 Graph Thinking With GraphQL 3 Graphs In The Database 4 The Neo4j GraphQL Library PART 2: BUILDING THE FRONT END 5 Building User Interfaces With React 6 Client Side GraphQL With React & Apollo Client PART 3: FULLSTACK CONSIDERATIONS 7 Adding Authorization & Authentication 8 Deploying Our Full Stack GraphQL Application 9 Advanced GraphQL Considerations APPENDIXES: A Installation instructions B GRANDstack starter project ©Manning Publications Co. To comment go to liveBook https://livebook.manning.com/#!/book/fullstack-graphql-applications/discussion

📄 Page 5

1 This chapter covers In this chapter we take an introductory look at the technologies we will use throughout the book, specifically: GraphQL - for building our API React - for building our user interface and JavaScript client web application Apollo - tools for working with GraphQL, on both the server and client Neo4j Database - the database we will use for storing and manipulating our application data Building a full stack GraphQL application involves working with a multi-tier architecture commonly known as a "three-tier application": a frontend application, the API layer, and a database. What Is Full Stack GraphQL? An overview of the components that make up a typical full stack GraphQL application A review of each technology used throughout the book (GraphQL, React, Apollo, and Neo4j Database) and how each piece fits together in the context of a full stack application A look at the requirements for the application we will build throughout the remainder of the book 1.1 A Look At Full Stack GraphQL ©Manning Publications Co. To comment go to liveBook https://livebook.manning.com/#!/book/fullstack-graphql-applications/discussion 1

📄 Page 6

Figure 1.1 The components of a full stack GraphQL application: GraphQL, React, Apollo, Neo4j Database Throughout the course of this book we will use these technologies to build a simple business reviews application, working through each technology component as we implement it in the context of our application. In the last section of this chapter we review the basic requirements of the application we will be building throughout the book. The focus of this book is learning how to build applications with GraphQL, so as we cover GraphQL it will be done in the context of building a full stack application and being used with other technologies: how to design our schema, how to integrate with a database, how to build a web application that can query our GraphQL API, how to add authentication to our application, and so on. As a result this book assumes some basic knowledge of how web applications are typically built, but does not necessarily require experience with each specific technology. To be successful the reader should have a basic familiarity with JavaScript, both client side and Node.js, and be familiar with concepts such as APIs and databases. You should have installed and should be familiar with the basics of the command line tool (or ) and how tonode npm yarn use it to create Node.js projects and install dependencies. We include a brief introduction to each technology and suggest other resources for more in-depth coverage where needed by the reader. It is also important to note that we will be covering specific technologies to be used alongside GraphQL and that at each phase a similar technology could be substituted (for example we could build our front-end using Vue instead of React). Ultimately the goal of this book is to show how these technologies fit together and provide the reader with a full stack framework for thinking about and building applications with GraphQL. ©Manning Publications Co. To comment go to liveBook https://livebook.manning.com/#!/book/fullstack-graphql-applications/discussion 2

📄 Page 7

At its core GraphQL is a specification for building APIs. The GraphQL specification describes an API query language and a way for fulfilling those requests. When building a GraphQL API we describe the data available using a strict type system. These type definitions become the specification for the API, and the client is free to request the data it requires based on these type definitions, which also define the entry points for the API. GraphQL is typically framed as an alternative to REST, which is the API paradigm you are mostly likely to be familiar with. This can be true in some cases, however GraphQL can also wrap existing REST APIs or other data sources. This is due to the benefit of GraphQL being data layer agnostic - we can use GraphQL with any data source. GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. – graphql.org Let’s dive into some more specific aspects of GraphQL. Rather than being organized around endpoints that map to resources (as with REST), GraphQL APIs are centered around type definitions that define the data types, fields, and how they are connected in the API. These type definitions become the schema of the API, which is served from a single endpoint. Since GraphQL services can be implemented in any language, a language agnostic GraphQL Schema Definition Language (SDL) is used to define GraphQL types. Let’s look at an example, motivated by considering a simple movies application. Imagine you’ve been hired to create a website that allows users to search a movie catalog for movie details such as title, actors, and description, as well as show recommendations for similar movies the user may find interesting. 1.2 GraphQL 1.2.1 GraphQL Type Definitions ©Manning Publications Co. To comment go to liveBook https://livebook.manning.com/#!/book/fullstack-graphql-applications/discussion 3

📄 Page 8

Figure 1.2 A simple movies web application Let’s start by creating some simple GraphQL type definitions that will define the data domain of our application: Listing 1.1 Simple GraphQL type definitions for a movies GraphQL API is a GraphQL object type, which means a type that contains one or moreMovie fields. is a field on the type.title Movie type Movie { movieId: ID! title: String actors: [Actor] } type Actor { actorId: ID! name: String movies: [Movie] } type Query { allActors: [Actor] allMovies: [Movie] movieSearch(searchString: String!): [Movie] moviesByTitle(title: String!): [Movie] } ©Manning Publications Co. To comment go to liveBook https://livebook.manning.com/#!/book/fullstack-graphql-applications/discussion 4

📄 Page 9

Fields can reference other types, such as a list of objects in this case.Actor is a required (or non-nullable) field on the type, which is indicatedactorId Actor by the character.! The type is a special type in GraphQL which indicate the entry points forQuery the API. Fields can also have arguments, in this case the field takes a requiredmovieSearch String argument, .searchString Our GraphQL type definitions declare the types used in the API, their fields, and how they are connected. When defining an object type (such as ) all fields available on the object andMovie the type of each field is also specified (we can also add fields later, using the keyword).extend In this case we define to be a scalar type - a type that resolves to a single value, astitle String opposed to an object type, which can contain multiple fields and references to other types. Here is a field on the type that resolves to an array of objects, indicating that theactors Movie Actor actors and movies are connected (the foundation of the "graph" in GraphQL). Fields can be either optional or required. The field on the object type is requiredactorId Actor (or non-nullable). This means that every object must have a value for . Fields thatActor actorId do not include a are nullable, meaning values for those fields are optional.! The fields of the type become the entry points for queries into the GraphQL service.Query GraphQL schemas may also contain a type, which defines the entry points for writeMutation operations into the API. A third special entry point related type is the type, whichSubscription defines events to which a client can subscribe. NOTE We’re skipping over many important GraphQL concepts here, such as mutation operations, interface and union types, and so on, but don’t worry we’re just getting started and will get to these soon enough! At this point you may be wondering where the "graph" is in "GraphQL". It turns out we’ve defined a graph using our GraphQL type definitions above. A graph is a data structure composed of nodes (the entities or objects in our data model) and relationships that connect nodes, which is exactly the structure we’ve defined in our type definitions using SDL. The GraphQL type definitions above have defined a simple graph with the following structure. Figure 1.3 GraphQL type definitions for our movie web application expressed as a graph diagram. ©Manning Publications Co. To comment go to liveBook https://livebook.manning.com/#!/book/fullstack-graphql-applications/discussion 5

📄 Page 10

Graphs are all about describing connected data and here we’ve defined how our movies and actors are connected in a graph. GraphQL allows us to model application data as a graph and traverse the data graph through GraphQL operations. When a GraphQL service receives an operation (such as a GraphQL query) it is validated and executed against the GraphQL schema defined by these type definitions. Let’s look at an example query that could be executed against a GraphQL service defined using the above type definitions. GraphQL queries define a traversal through the data graph defined by our type definitions as well as requesting a subset of fields to be returned by the query - this is known as the selection . In this query we start from the Query field entry point and traverse the graph toset allMovies find actors connected to each movie. Then for each of these actors, we traverse to all the other movies they are connected to. Listing 1.2 A GraphQL query to find movies and actors Optional naming of operation, is the default operation and can therefore bequery omitted. Naming the query, in this case is also optional and canFetchSomeMovies be omitted. Here we specify the entry point, which is a field on either the or Query Mutation type, in this case our entry point for the query is the query field.allMovies The selection set defines the fields to be returned by the query. In the case of object fields, a nested selection set is used to specify the fields to be returned. A further nested selection is needed for the fields on to be returned.movies Note that our query is nested and describes how to traverse the graph of related objects (in this case movies and actors). We can represent this traversal through the data graph and the results visually. 1.2.2 Querying With GraphQL query FetchSomeMovies { allMovies { title actors { name movies { title } } } } ©Manning Publications Co. To comment go to liveBook https://livebook.manning.com/#!/book/fullstack-graphql-applications/discussion 6

📄 Page 11

Figure 1.4 A GraphQL query traversal through the movies data graph Although we can represent the traversal of the GraphQL visually, the typical result of a GraphQL query is a JSON document. "name": "Robin Williams", "movies": [ Listing 1.3 JSON query results "data": { "allMovies": { "title": "Toy Story", "actors": [ { "name": "Tom Hanks", "movies": [ { "title": "Bachelor Party" } ] }, { "name": " Jim Varney", "movies": [ { "title": "3 Ninjas: High Noon On Mega Mountain" } ] } ] }, { "title": "Jumanji", "actors": [ { ©Manning Publications Co. To comment go to liveBook https://livebook.manning.com/#!/book/fullstack-graphql-applications/discussion 7

📄 Page 12

"name": "Robin Williams", "movies": [ { "title": "Popeye" } ] }, { "name": "Kirsten Dunst", "movies": [ { "title": "Midnight Special" }, { "title": "All Good Things" } ] } ] }, { "title": "Grumpier Old Men", "actors": [ { "name": "Walter Matthau", "movies": [ { "title": "Cactus Flower" } ] }, { "name": " Ann-Margret", "movies": [ { "title": "Bye Bye Birdie" } ] } ] } ] } ©Manning Publications Co. To comment go to liveBook https://livebook.manning.com/#!/book/fullstack-graphql-applications/discussion 8

📄 Page 13

As you can see from the results, the response matches the shape of the query’s selection set - exactly the fields requested in the query are returned. But where does the data come from? The data fetching logic for GraphQL APIs is defined in functions called , which contain the logic for resolving the data for an arbitraryresolver functions GraphQL request from the data layer. GraphQL is data layer agnostic so the resolvers could query one or more databases or even fetch data from another API, even a REST API. We will cover resolvers in depth in the next chapter. Now that we’ve seen our first GraphQL query you may be wondering, "OK that’s nice, but I can fetch data about movies with REST, too. What’s so great about GraphQL?". Let’s review some of the benefits of GraphQL. Overfetching refers to a pattern commonly associated with REST where unnecessary and unused data is sent over the network in response to an API request. Since REST is modeling resources, when we make a request for say we get back the representation of thatGET /movie/tt0105265 movie, nothing more nothing less. Listing 1.4 REST API response for GET /movie/tt0105265 But what if the view of our application only needs to render the title and year of the movie? Then we’ve unnecessarily sent too much data over the network. Further, some of those movie fields may be expensive to compute. For example if we need to calculate byaverageReviews aggregating across all movie reviews for each request, but we’re not even showing that in the application view, that’s a lot of wasted compute time and unnecessarily impacts the performance 1.2.3 Advantages of GraphQL OVERFETCHING AND UNDERFETCHING { "title": "A River Runs Through It", "year": 1992, "rated": "PG", "runtime": "123 min", "plot": "The story about two sons of a stern minister -- one reserved, one rebellious -- growing up in rural Montana while devoted to fly fishing.", "movieId": "tt0105265", "actors": ["nm0001729", "nm0000093", "nm0000643", "nm0000950"], "language": "English", "country": "USA", "production": "Sony Pictures Home Entertainment", "directors": ["nm0000602"], "writers": ["nm0533805", "nm0295030"], "genre": "Drama", "averageReviews": 7.3 } ©Manning Publications Co. To comment go to liveBook https://livebook.manning.com/#!/book/fullstack-graphql-applications/discussion 9

📄 Page 14

of our API (of course in the real world we may cache this, but that adds additional complexity as well). Similarly, underfetching is a pattern associated with REST where not enough data is returned by the request. Let’s say our application view needs to render the name of each actor in a movie. First we make a GET request for . As seen above we have an array of IDs for the actors/movie/tt0105265 connected to this movie. Now to get the data required for our application we need to iterate over this array of actor IDs to get the name of each actor by making another API request for each actor to be rendered in our view. With GraphQL we can accomplish this in a single request by specifying exactly the data needed by the application view in the selection set of the GraphQL query, solving both the overfetching and underfetching problems. This results in improved performance on the server side as we are spending less compute resources at the data layer, less overall data sent over the network, and reduced latency by being able to render our application view with a single network request to the API service. GraphQL is a specification for client-server communication that describes the features, functionality and capability of the GraphQL API query language. Having this specification gives a clear guide of how to implement your GraphQL API and clearly defines what is and what is not GraphQL. REST does not have a specification, instead there are many different implementations, from what might be considered merely REST-ish to Hypermedia As The Engine Of Application State (HATEOAS). Having a specification as part of GraphQL simplifies debates over endpoints, status codes, and documentation. All of this comes built in with GraphQL which leads to productivity wins for developers and API designers. The specification provides a clear path for API implementors. /actor/nm0001729 /actor/nm0000093 /actor/nm0000643 /actor/nm0000950 GRAPHQL SPECIFICATION ©Manning Publications Co. To comment go to liveBook https://livebook.manning.com/#!/book/fullstack-graphql-applications/discussion 10

📄 Page 15

REST models itself as a hierarchy of resources, yet most interactions with APIs are done in terms of relationships. For example, given our movie query above - for this movie, show me all of the actors connected to it, and for each actor show me all the other movies they’ve acted in - we’re querying for relationships between actors and movies. This concept of relationships is even more prominent in real world applications where we might be working with the relationships connecting customers and the products in their orders, or users and their messages to other users in the context of a conversation. GraphQL can also help unify data from disparate systems. Since GraphQL is data layer agnostic we can build GraphQL APIs that integrate data from multiple services together and provide a clear way to integrate data from these different systems into a single unified GraphQL schema. GraphQL can also be used to compartmentalize data fetching in the application in a component based data interaction pattern. Since each GraphQL query can describe exactly the graph traversal and fields to be returned, encapsulating these queries with application components can help simplify application development and testing. We’ll see how to apply this once we start building our React application in Chapter 5. Introspection is a powerful feature of GraphQL that allows us to ask a GraphQL API for the types and queries it supports. Introspection becomes a way of self-documenting the API. Tools that make use of introspection can provide human readable API documentation, visualization tooling, and leverage code generation to create API clients. Of course GraphQL is not a silver bullet and we should not think of GraphQL as the solution to all of our API-related problems. One of the most notable challenges of adopting GraphQL is that some well understood practices from REST don’t apply when using GraphQL. For example, HTTP status codes are commonly used to convey success, failure and other cases of a REST request: 200 OK means our request was successful and 404 Not Authorized means we forgot an auth token or don’t have the correct permissions for the resource requested. However with GraphQL, each request returns 200 OK, regardless of if the request was a complete success or not. This makes error handling a bit different in the GraphQL world. Instead of a single status code describing the result of our request, GraphQL errors are typically returned at the field level. This means that we may have successfully retrieved a part of our GraphQL query, while other fields returned errors and will need to be handled appropriately. Caching is another well understood area from REST that is handled a bit differently with GraphQL. With REST, caching the response for is possible because we can return/movie/123 the same exact result for each GET request. This isn’t possible with GraphQL because each WITH GRAPHQL IT’S GRAPHS ALL THE WAY DOWN INTROSPECTION 1.2.4 Disadvantages of GraphQL ©Manning Publications Co. To comment go to liveBook https://livebook.manning.com/#!/book/fullstack-graphql-applications/discussion 11

📄 Page 16

request could contain a different selection set, meaning we can’t simply return a cached result for the whole request. This is mitigated by most GraphQL clients implementing client caches at the application level and in practice much of the time our GraphQL requests are in an authenticated environment where caching isn’t applicable. Another challenge is that of exposing arbitrary complexity to the client and related performance considerations. If the client is free to compose queries as they wish, how can we ensure these queries don’t become so complex as to impact performance significantly or overwhelm the computing resources of our backend infrastructure? Fortunately, GraphQL tooling allows us to restrict the depth of the queries used and further restrict the queries that can be run to a whitelisted selection of queries (known as persisted queries). A related challenge is implementing rate limiting. With REST we could simply restrict the number of requests that can be made in a certain time period, however with GraphQL this becomes more complicated since the client could be requesting multiple objects in a single query. This results in bespoke query costing implementations to address rate limiting. Finally, the so called "n+1 query problem" is a common problem in GraphQL data fetching implementations that can result in multiple round trips to the data layer and can negatively impact performance. Consider the case where we request information about a movie and all actors of the movie. In the database we might store a list of actor IDs associated with each movie, which is returned with our request for the movie details. In a naive GraphQL implementation we would then need to retrieve the actor details and we must make a separate request to the database for each actor object, resulting in a total of n (the number of actors) + 1 (the movie) queries to the database. To address the n+1 query problem tools like DataLoader allow us to batch and cache requests to the database, increasing performance. Another approach to addressing the n+1 query problem are GraphQL database integrations such as the Neo4j GraphQL library and PostGraphile that allow us to generate a single database query from an arbitrary GraphQL request, ensuring only a single roundtrip to the database. SIDEBAR GraphQL Limitations While we’re talking about databases it is important to understand that GraphQL is an API query language and not a database query language. GraphQL lacks semantics for many complex operations required of database query languages, such as aggregations, projects, and variable length path traversals. ©Manning Publications Co. To comment go to liveBook https://livebook.manning.com/#!/book/fullstack-graphql-applications/discussion 12

📄 Page 17

In this section we review some GraphQL specific tooling that will help us build, test, and query our GraphQL API. These tools leverage GraphQL’s introspection feature, allowing for extracting the schema of a deployed GraphQL endpoint to generate documentation, query validation, auto-completion and other useful development functionality. GraphiQL is an in-browser tool for exploring and querying GraphQL APIs. With GraphiQL we can execute GraphQL queries against a GraphQL API and view the results. Thanks to GraphQL’s introspection feature we can view the types, fields, and queries supported by the GraphQL API we’ve connected to. In addition, because of the GraphQL type system we have immediate query validation as we construct our query. GraphiQL is an open-source package now maintain by the GraphQL Foundation. GraphiQL is packaged as either a stand-alone tool or a React component and therefore is often embedded in larger web applications. Figure 1.5 GraphiQL screenshot 1.2.5 GraphQL Tooling GRAPHIQL ©Manning Publications Co. To comment go to liveBook https://livebook.manning.com/#!/book/fullstack-graphql-applications/discussion 13

📄 Page 18

Similar to GraphiQL, GraphQL Playground is an in-browser tool for executing GraphQL queries, viewing the results, and exploring the GraphQL API’s schema, powered by GraphQL’s introspection feature. GraphQL Playground has a few additional features such as viewing GraphQL type definitions, searching through the GraphQL schema, and easily adding request headers (such as those required for authentication). GraphQL Playground was once included by default in server implementations such as Apollo Server, however has since been deprecated and is no longer actively maintained. We include GraphQL Playground here since it is still deployed in many GraphQL endpoints and you will likely come across it at some point. Figure 1.6 GraphQL Playground screenshot Apollo Studio is a cloud platform from Apollo that includes many features for building, validating and securing GraphQL APIs. Apollo Studio is included in this section because the "Explorer" feature of Studio is similar to the GraphiQL and GraphQL Playground tools mentioned above for creating and running GraphQL operations. Also, the Explorer in Apollo Studio is now used by default by Apollo Server (as of version 3 of Apollo Server) so we will be using Apollo Studio throughout this book to run GraphQL operations against our GraphQL API as we develop it. GRAPHQL PLAYGROUND APOLLO STUDIO ©Manning Publications Co. To comment go to liveBook https://livebook.manning.com/#!/book/fullstack-graphql-applications/discussion 14

📄 Page 19

Figure 1.7 Apollo Studio screenshot React is a declarative, component based library for building user interfaces using JavaScript. React uses a virtual DOM (a copy of the actual Document Object Model) to efficiently calculate DOM updates required to render views as application state and data changes. This means users simply design views that map to application data and React handles rendering the DOM updates efficiently. Components encapsulate data handling and user interface rendering logic without exposing their internal structure so they can easily be composed together to build more complex user interfaces and applications. Let’s examine a simple React component: Listing 1.5 A simple React component We import React and the hook for managing state variables.useState Our component is a function that is passed "props" or values from other components higher in the React component hierarchy. 1.3 React 1.3.1 React Components import React, { useState } from "react"; function MovieTitleComponent(props) { const [movieTitle, setMovieTitle] = useState("River Runs Through It, A") return ( <div>{movieTitle}</div> ) } export default MovieTitleComponent; ©Manning Publications Co. To comment go to liveBook https://livebook.manning.com/#!/book/fullstack-graphql-applications/discussion 15

📄 Page 20

Using the hook we create a new state variable and the associateduseState function for updating this value. Here we access the value from our component state and render thatmovieTitle inside a tag.div We export this component so it can be composed in other React components. Since components encapsulate data handling and user interface rendering logic and are easily composable, it becomes practical to distribute libraries of components that can be used as dependencies of our project for quickly leveraging complex styling and user interface design. Using such component libraries is beyond the scope of this book, however a good example is the Material-UI component library which allows us to import many popular common user interface components such as a grid layout, data table, navigation, and inputs. React is typically used with a JavaScript language extension called JSX. JSX looks similar to XML and is a powerful way of building user interfaces in React and composing React components. It is possible to use React without JSX, but most users prefer the readability and maintainability that JSX offers. We will introduce JSX in Chapter 5 as well as a number of other React concepts such as unidirectional data flow, props and state, as well as data fetching with React. Here we review some useful tooling that will help us build, develop, and troubleshoot React applications. Create React App is a command line tool that can be used to quickly create the scaffolding for a React application, taking care of configuring build settings, installing dependencies, and templating a simple React application to get started. React Devtools is a browser extension that lets us inspect a React application, seeing under the hood the component hierarchy and the props and state of each component while our application is running. COMPONENT LIBRARIES 1.3.2 JSX 1.3.3 React Tooling CREATE REACT APP REACT CHROME DEVTOOLS ©Manning Publications Co. To comment go to liveBook https://livebook.manning.com/#!/book/fullstack-graphql-applications/discussion 16