The GraphQL Guide (r5) (John Resig, Loren Sands-Ramshaw) (z-library.sk, 1lib.sk, z-lib.sk)

📄 File Format: PDF

💾 File Size: 38.4 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

1.1 1.2 1.2.1 1.2.2 1.2.3 1.2.4 1.2.4.1 1.2.4.2 1.2.5 1.2.6 1.3 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5 1.3.6 1.3.7 1.3.8 1.3.8.1 1.3.8.2 1.3.8.3 1.3.9 1.3.10 1.3.11 1.3.12 1.3.13 1.3.14 1.3.15 1.3.16 1.3.17 1.3.17.1 1.3.17.2 1.3.18 1.4 1.4.1 1.4.2 Table of Contents Preface Introduction Who is this book for? Background The book The code Git Formatting Resources Version Background JavaScript JavaScript classes JSON Git Node, npm, and nvm HTTP Server Databases MongoDB Redis SQL SPA SSR React Latency CDN Webhooks Testing Continuous integration Authentication Tokens vs. sessions localStorage vs. cookies Browser performance Chapter 1: Understanding GraphQL Through REST Introduction GraphQL as an alternative to a REST API 2

📄 Page 3

1.4.3 1.4.4 1.4.5 1.4.6 1.4.7 1.4.8 1.4.9 1.4.10 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.1.7 2.1.8 3.1 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7 3.1.8 3.1.9 3.1.10 4.1 4.1.1 4.1.2 4.1.3 4.1.4 5.1 5.1.1 A simple REST API server A simple GraphQL server Querying a set of data Filtering the data Async data loading Multiple types of data Security & error handling Tying this all together Part I: The Spec Chapter 2: Query Language Document Fields Arguments Fragments Variables Directives Mutations Subscriptions Chapter 3: Type System Schema Scalar types Enum types Object types Query & Mutation types Lists Non-null Arguments Unions Interfaces Chapter 4: Validation & Execution Validation Resolvers Execution Error handling Part II: The Client Chapter 5: Client Dev Anywhere: HTTP 3

📄 Page 4

5.1.1.1 5.1.1.2 5.1.2 5.1.2.1 5.1.2.2 5.1.2.3 5.1.2.4 5.1.2.5 6.1 6.1.1 6.1.1.1 6.1.1.2 6.1.1.3 6.1.2 6.1.2.1 6.1.2.2 6.1.2.3 6.1.2.4 6.1.2.5 6.1.2.6 6.1.2.7 6.1.3 6.1.3.1 6.1.3.2 6.1.4 6.1.4.1 6.1.4.2 6.1.4.3 6.1.4.4 6.1.4.5 6.1.4.6 6.1.4.7 6.1.4.8 6.1.4.9 6.1.5 6.1.5.1 6.1.5.1.1 6.1.5.1.1.1 6.1.5.1.1.2 6.1.5.1.2 cURL JavaScript Client libraries Streamlined request function Typing View layer integration Caching DevTools Chapter 6: React Setting up Build options App structure Set up Apollo Querying First query Loading Polling Subscriptions Lists Query variables Skipping queries Authentication Logging in Resetting Mutating First mutation Listing reviews Optimistic updates Arbitrary updates Creating reviews Using fragments Deleting Error handling Editing reviews Advanced querying Paginating Offset-based page skip & limit Cursors 4

📄 Page 5

6.1.5.1.2.1 6.1.5.1.2.2 6.1.5.2 6.1.5.3 6.1.5.3.1 6.1.5.3.2 6.1.5.4 6.1.5.5 6.1.5.5.1 6.1.5.5.2 6.1.5.5.3 6.1.5.6 6.1.5.6.1 6.1.5.6.2 6.1.5.7 6.1.5.8 6.1.5.9 6.1.6 6.1.6.1 6.1.6.1.1 6.1.6.1.2 6.1.6.1.3 6.1.6.2 6.1.6.3 7.1 8.1 9.1 10.1 11.1 11.1.1 11.1.1.1 11.1.1.2 11.1.2 11.1.2.1 11.1.2.2 11.1.2.3 11.1.2.4 after orderBy Updating multiple queries Local state Direct writes Local mutations REST Review subscriptions Subscription component Add new reviews Update on edit and delete Prefetching On mouseover Cache redirects Batching Persisting Multiple endpoints Extended topics Linting Setting up linting Fixing linting errors Using linting Uploading files Testing Chapter 7: Vue Chapter 8: React Native Chapter 9: iOS Chapter 10: Android Part III: The Server Chapter 11: Server Dev Introduction Why build a GraphQL server? What kind of GraphQL server should I build? Building Project setup Types and resolvers Authentication Data sources 5

📄 Page 6

11.1.2.4.1 11.1.2.4.2 11.1.2.4.3 11.1.2.5 11.1.2.6 11.1.2.6.1 11.1.2.6.2 11.1.2.6.3 11.1.2.7 11.1.2.8 11.1.2.8.1 11.1.2.8.2 11.1.2.8.3 11.1.2.8.3.1 11.1.2.8.3.2 11.1.2.8.4 11.1.2.8.5 11.1.2.9 11.1.2.9.1 11.1.2.9.2 11.1.3 11.1.3.1 11.1.3.2 11.1.3.3 11.1.3.4 11.1.3.5 11.1.3.6 11.1.4 11.1.4.1 11.1.4.1.1 11.1.4.1.2 11.1.4.1.3 11.1.4.2 11.1.4.2.1 11.1.4.2.2 11.1.4.2.2.1 11.1.4.2.2.2 11.1.4.3 11.1.4.4 11.1.4.5 Setting up File structure Creating reviews Custom scalars Creating users Protecting with secret key Setting user context Linking users to reviews Authorization Errors Nullability Union errors formatError Logging errors Masking errors Error checking Custom errors Subscriptions githubStars reviewCreated Testing Static testing Review integration tests Code coverage User integration tests Unit tests End-to-end tests Production Deployment Options Deploying Environment variables Database hosting MongoDB hosting Redis hosting Redis PubSub Redis caching Querying in production Analytics Error reporting 6

📄 Page 7

11.1.5 11.1.5.1 11.1.5.1.1 11.1.5.1.2 11.1.5.1.3 11.1.5.1.4 11.1.5.2 11.1.5.3 11.1.5.4 11.1.5.5 11.1.6 11.1.6.1 11.1.6.2 11.1.6.2.1 11.1.6.2.2 11.1.6.2.2.1 11.1.6.2.2.2 11.1.6.3 11.1.6.3.1 11.1.6.3.2 11.1.6.4 11.1.6.5 11.1.6.5.1 11.1.6.5.2 11.1.6.5.3 11.1.6.5.4 11.1.6.5.5 11.1.6.6 11.1.6.7 11.1.6.7.1 11.1.6.7.2 11.1.6.7.3 11.1.6.7.4 11.1.6.7.5 11.1.6.7.5.1 11.1.6.7.5.2 11.1.6.7.6 11.1.6.8 11.1.6.8.1 11.1.6.8.2 More data sources SQL SQL setup SQL data source SQL testing SQL performance REST GraphQL Custom data source Prisma Extended topics Mocking Pagination Offset-based Cursors after an ID Relay cursor connections File uploads Client-side Server-side Schema validation Apollo federation Federated service Federated gateway Extending entities Managed federation Deploying federation Hasura Schema design One schema User-centric Easy to understand Easy to use Mutations Arguments Payloads Versioning Custom schema directives @tshirt @upper 7

📄 Page 8

11.1.6.8.3 11.1.6.9 11.1.6.9.1 11.1.6.9.2 11.1.6.10 11.1.6.10.1 11.1.6.10.1.1 11.1.6.10.1.2 11.1.6.10.2 11.1.6.11 11.1.6.11.1 11.1.6.11.2 11.1.6.12 @auth Subscriptions in depth Server architecture Subscription design Security Auth options Authentication Authorization Denial of service Performance Data fetching Caching Future 8

📄 Page 9

Preface Hello there, dear reader . Welcome to the Guide! We are John and Loren, your authors. John created jQuery, and Loren is slightly less famous but writes good . We’re here to tell you about GraphQL, the system we believe will eclipse REST as the best way to fetch data from servers. We’ll get into why in Chapter 1, but for now, here’s the story of this book: GraphQL was released in mid 2015, and its adoption has been accelerating ever since. In 2016, Github switched its API from REST to GraphQL. In 2017, AWS launched a GraphQL-based platform for building apps. Both npm and the State of JavaScript survey named 2018 the year of GraphQL. John and Loren both realized early on that A) GraphQL was going to be very important for app development, and B) a great book on GraphQL didn’t yet exist! We each decided independently to write one, but then we found each other and—over schnitzel at a biergarten in Brooklyn— decided to join forces. We’re writing the complete reference: what GraphQL is, why to use it, and most importantly, how to use it—on the server, in the browser, on mobile, with React, React Native, Vue, Node, Java, and Swift. We’ll take you step-by-step through building an app, so you can see the practical need behind each part of GraphQL. We’re doing it as an ebook so we can always keep it up to date. A physical book would quickly fall behind best practices in such a fast-moving space. We’d like to thank everyone who helped out with this book, including our technical reviewers Tom Coleman, Brad Crispin, Abhi Aiyer, Oleksandr Bordun, Heather Armstrong, Justin Krup, Melek Hakim, Kamal Radharamanan, Lewi Gilamichael, and Enno Thoma, our designer Genki Hagata, and our copy editors Lauren Itzla, Rachel Lake, and Paul Ramshaw. We’d also like to thank those who wrote the libraries on which this book is based, especially the GraphQL and Apollo communities. If you’d like to improve this resource for those who read after you, we welcome your suggestions in the form of GitHub issues or PRs on the book text repo and the code repo . We’ve found that building apps with GraphQL is less difficult and more fun, and we think you’ll be similarly impressed. We hope you enjoy . John Resig and Loren Sands-Ramshaw Brooklyn, New York June, 2018 © 2020 The GraphQL Guide Preface 9

📄 Page 10

Introduction Who is this book for? Background The book The code Git Formatting Resources Version Who is this book for? This book is for most programmers. If you write software that fetches data from a server, or you write server code that provides data to others, this book is for you. It’s particularly relevant to frontend and backend web and mobile developers. If you don’t know modern JavaScript, we recommend learning that first, but it’s not necessary. For example, if you only know Ruby, you can likely follow the JavaScript server code in Chapter 11 well enough to learn the important concepts of a GraphQL server, most of which will apply to using the graphql gem in your Ruby server code. This book will be especially poignant to these groups of people: Backend devs who work on REST APIs and who: write a lot of similar code to fetch data and format it into JSON, maintain view- or device-specific endpoints, or have multiple APIs that use overlapping business data. Frontend devs who either: don’t use a caching library, and manually keep track of what data has already been fetched from the server, or use a cache, and write a lot of code to fetch data over REST and put it in the cache (we’re looking at you, Reduxers ). Background We have a Background chapter that provides concise introductions to various background topics. You’re welcome to either look through them now or individually as you go along—at the beginning of a section, you’ll find a list of topics it assumes knowledge of, like the Anywhere: HTTP section, which has two listed: Background: HTTP, JSON Some topics like Git and Node are necessary for following along with the coding. Others, like Tokens vs. sessions, are nice to know, but not necessary. The book Introduction 10

📄 Page 11

While this book is great when read cover-to-cover, it’s organized as a reference text, so you can also use it to look up a specific topic. For instance, if you’re familiar with most GraphQL types but want to learn about Unions, you can look them up in the Table of Contents under Chapter 3: Type System—Section 9: Unions. Or if you’re already doing basic queries in your React app, and you want to implement infinite scrolling, you can look it up under Chapter 6: React— Section 5: Advanced querying—Paginating. Chapter 1 introduces GraphQL and shows why it’s better than REST. Chapters 2 and 3 explain the language itself and its type system. Chapter 4 goes in depth on how a GraphQL server responds to a query. It’s great for a full understanding of the technology, but you don’t need to know it unless you’re contributing to a GraphQL server library. So it’s totally fine to skip this—you’ll still understand everything if you go straight to Chapter 11, the practical server-coding chapter. Chapter 5: Client Dev is the first of the coding chapters, and introduces common concepts among client libraries. Then we have a chapter for each library: Chapter 6: React Chapter 7: Vue Chapter 8: React Native Chapter 9: iOS Chapter 10: Android Chapter 11: Server Dev is our looooong server-coding chapter . All of the examples are in Node with the apollo- server-express library, but almost all of the concepts can be applied to other languages’ GraphQL libraries. The code We intersperse blocks of code throughout the text. When we add code to a file that we’ve shown previously, we often just display the additions and some context, with ellipses ( ... ) in place of existing code. These additions will be clearest if you read the book with the code open in another window. Further, we believe humans usually learn better if they write things out themselves, so we encourage you to write out the code for each step, and get it working on your computer before moving on to the next step. We recommend using Chrome and VS Code. Code snippets are better formatted and sized in the PDF version of the book. If you’re reading this in EPUB or MOBI format on your phone, turning sideways into landscape mode will help reduce code snippet wrapping. Git In Chapters 6–11, you’ll learn through writing an app, step by step. Each chapter has its own repository. Each step has a branch in that repo, for example, branch 0 is the starter template, branch 1 has the code you write in step 1, etc. The branches we link to in the text also have a version number, and have the format: [step]_[version] . When the first version of the Guide was published, the Chapter 6 code version was 0.1.0 , so step 1 linked to branch 1_0.1.0 . The current version is 0.2.0 , so step 1 links to 1_0.2.0 . If you skip the beginning of Chapter 6 and go straight to the Listing reviews section, it says to start with step 9 ( 9_0.2.0 ). So we can look at the app in that state with these terminal commands: git clone https://github.com/GraphQLGuide/guide.git cd guide/ git checkout 9_0.2.0 npm install npm start Introduction 11

📄 Page 12

Check out the git and npm background sections if you’re unfamiliar with these commands. If we get stuck, we can look at the diff between step 9 and step 10 with GitHub’s compare feature: github.com/[repository]/compare/[tag 1]...[tag 2] which in our case would be: github.com/GraphQLGuide/guide/compare/9_0.2.0...10_0.2.0 We can also see the solution to the current step by checking out the next step: git checkout 10_0.2.0 npm start Formatting All the JavaScript code is ES2016 and formatted with prettier with two settings: .prettierrc singleQuote: true semi: false This means ' instead of " for string literals and no unnecessary semicolons. Resources If you run into issues, we recommend posting to Stack Overflow with the relevant tag, for instance react-apollo for Chapter 6. If you have the Full edition, you can also ask the community in the #support Slack channel or email the technical support address we gave you. If the issue is with our code, please search the repository’s issues to see if it’s an existing bug, and if it’s new, submit it! github.com/GraphQLGuide/guide/issues Another important resource is the docs! Here they are for each library: Chapter 6 and 8: react-apollo Chapter 7: vue-apollo Chapter 9: Apollo iOS Chapter 10: Apollo-Android Chapter 11: apollo-server-express Version Book version: r5 (changelog) Published May 23, 2020 As we write more of the book, we’ll send you new versions of it (using the email address on the GitHub account you connected when you purchased the book from graphql.guide). Introduction 12

📄 Page 13

Chapter 6 Code version: 0.2.0 (changelog) react-apollo 2.5 graphql 0.14 react 16.8 Chapter 11 Code version: 0.2.0 (changelog) apollo-server 2.12.0 Introduction 13

📄 Page 14

Chapter: Background Chapter contents: JavaScript JavaScript classes JSON Git Node, npm, and nvm HTTP Server Databases MongoDB Redis SQL SPA SSR React Latency CDN Webhooks Testing Continuous integration Authentication Tokens vs. sessions localStorage vs. cookies Browser performance This chapter provides concise introductions to various background topics. You’re welcome to either read them all up front or individually as you go along—at the beginning of a section, you’ll find a list of topics it assumes knowledge of, like the Anywhere: HTTP section, which has two listed: Background: HTTP, JSON Some topics, like Git and Node, are necessary for following along with the coding. Others, like Tokens vs. sessions, are nice to know, but not necessary. JavaScript Most of the code in the book is in modern JavaScript. If you’re new to JS, you can learn through interactive courses, video (intro and intermediate), or a combination. If you know traditional JS, but some of the new syntax is unfamiliar (for instance async/await), here’s a course on ES6. JavaScript classes Background 14

📄 Page 15

A class is a template for an object. With this class: class Animal { constructor(name) { this.name = name } speak() { console.log(`${this.name} makes a noise.`) } } We can make an object, or instance of the class: const loren = new Animal('Loren') loren is now an instance of Animal . When JavaScript evaluated new Animal('Loren') , it created a new object and called the constructor method with the string 'Loren' , which set the object’s property name to 'Loren' and (implicitly) returned the new object. Now when we do: console.log(loren.name) loren.speak() We see the output: Loren Loren makes a noise. The class Animal is a template that we can create multiple different instances of: const loren = new Animal('Loren') const graphy = new Animal('Graphy') loren.speak() graphy.speak() Results in: Loren makes a noise. Graphy makes a noise. Both of the instances have the .speak() method, but they have different values for the .name property, so .speak() logs different strings. We can also create subclasses by using the syntax class SubClass extends SuperClass : class Animal { constructor(name) { this.name = name console.log(`${this.name} is a ${this.constructor.name}.`) } speak() { console.log(`${this.name} makes a noise.`) } } class Dog extends Animal { constructor(name) { super(name) Background 15

📄 Page 16

console.log('Subspecies: Canis lupus familiaris.') } } Dog is a subclass of Animal . this.constructor.name is the name of the class ( 'Dog' if new Dog() or 'Animal' if new Animal() ). In its constructor, it calls the superclass’s constructor ( super(name) ) and then logs. So now if we do: const graphy = new Dog() console.log(graphy.name) graphy.speak() We see: Graphy is a Dog. Subspecies: Canis lupus familiaris. Graphy Graphy makes a noise. A subclass can override a superclass’s method or define new methods: class Dog extends Animal { constructor(name) { super(name) } speak() { console.log(`${this.name} barks.`) } } const loren = new Animal('Loren') loren.speak() const graphy = new Dog('Graphy') graphy.speak() graphy.sit() Loren is a Animal. Loren makes a noise. Graphy is a Dog. Subspecies: Canis lupus familiaris. Graphy barks. Graphy sits. If we tried to do loren.sit() , we would get an error because Animal doesn’t have a .sit() method: loren.sit() ^ TypeError: loren.sit is not a function We can have multiple subclasses, for instance Rabbit and Cat , and subclasses can have subclasses, for instance class Lynx extends Cat . JSON JSON is a file format for data objects. The objects are structured in attribute–value pairs, where the attribute is a string and the value can be one of the following types: Background 16

📄 Page 17

Number: 1.14 String: "foo" Boolean: true null: null Array of other types: ["foo", true, 1.14] Object: { "name": "john" } In JSON documents, whitespace doesn’t matter, and commas go between attribute–value pairs and between items in arrays. Here’s an example, formatted with nice whitespace: { "authors": [ { "name": "john", "wearsGlasses": true }, { "name": "loren", "wearsGlasses": true } ] } It’s also valid JSON to have an array at the top level of the document, e.g.: [{ "name": "john" }, { "name": "loren" }] In JavaScript, if we have this document in a string, we can parse it to create a JavaScript object with the same data: const jsObject = JSON.parse(jsonString) When working with raw HTTP responses that contain a JSON body, we have to use JSON.parse() to get the data into an object. But we’ll mostly be working with libraries that take care of this step for us. Git Git is a version control system for saving your code and keeping a history of the changes. Unfamiliar? Try this interactive tutorial Node, npm, and nvm Node is what runs JavaScript on a server. npm is a JavaScript package manager and registry. Their npm command- line tool manages the packages (libraries of JavaScript code) that our app depends on, helping us install and upgrade them. Their registry stores the content of the packages and makes them available for download—it has more packages than any other registry in the history of software! We use npm packages both with code that runs on the server in Node and with code that runs on the client—in the browser or in React Native. We recommend installing Node with nvm (the Node Version Manager): $ curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh | bash $ nvm install node $ nvm alias default node This installs the latest version of Node. Then in a new terminal window, we can see the version number with: Background 17

📄 Page 18

$ node -v We can keep track of which projects use which versions of node by adding a .nvmrc file to the root of each project. It contains a version number (like 8 or 8.11.3 ) or node to use the latest stable version. Then when we switch projects, we run nvm use to switch to that project’s version of node: $ nvm use Found '/guide/.nvmrc' with version <8> Now using node v8.11.3 (npm v5.6.0) npm is a command-line tool that is installed along with Node. When we want to use npm packages in our project, we create a package.json file in the project’s root directory: { "name": "my-project", "private": true } Then we install the package with: $ npm install graphql If we’re using a recent version of npm (5.0 or higher), the package name and version will now be saved in our package.json : { "name": "my-project", "private": true, "dependencies": { "graphql": "^0.13.1" } } We see the current package’s version, which was 0.13.1 at time of writing. npm packages follow SemVer, a convention for version numbering: [major version].[minor version].[patch version] Major version changes mean that the library’s API has been changed in an incompatible way—if we write our code to use version 1.0.0 of a library (for example, using the library’s function doThis() ), our code will probably break if we switch to version 2.0.0 . (For example, if the library renamed doThis to doThat , and our code were still called doThis() , we’d get an error.) Minor and patch version changes do not break the API—if we write our code using version 1.0.0 of a library, we can safely upgrade to version 1.0.8 or 1.4.0 . Minor version changes mean that functionality has been added—if we write our code using version 1.4.0 , it may break if we switch to version 1.3.0 , because it may use a feature introduced in minor version 4. Patch version changes mean that bugs have been fixed—if we switch from 1.0.8 to 1.0.7 , our code may stop working because of the bug that was fixed in patch version 8. The one exception to the above is that version numbers with a major version of 0 don’t have a stable API, so going from 0.0.1 to 0.0.2 could be breaking—as could going from 0.1.0 to 0.2.0 . A caret ̂ before a version number means that our code depends on any version compatible with that number—for example, if we had a dependency "foo": "^1.4.0" , our code should work with any versions between 1.4.0 and 2.0.0 , such as 1.4.1 or 1.11.2 . We can also see that we have a new node_modules/ folder, and it contains folders with the package code: Background 18

📄 Page 19

$ ls node_modules/ graphql iterall iterall was downloaded as well because it is a dependency of graphql , which we can see if we look at its package.json : $ cat node_modules/graphql/package.json { … "dependencies": { "iterall": "^1.2.0" }, "homepage": "https://github.com/graphql/graphql-js", "name": "graphql", "version": "0.13.1" } We don’t want to save downloaded packages in git, so we exclude it: $ echo 'node_modules/' >> .gitignore If we’re not in an existing git repository, we run git init to initialize. Then we can save our files with git add <filename> and a commit: $ git add package.json .gitignore $ git commit -m 'Added the graphql package' When our code is cloned (by others, or by us in the future), there will be no node_modules/ . If our code is at https://github.com/me/app , then we would do: $ git clone https://github.com/me/app.git $ cd app $ ls -a . .. .git .gitignore package.json We run npm install to download all the packages listed in package.json into node_modules/ : $ npm install added 2 packages in 1.026s $ ls node_modules/ graphql iterall And then we could use the package in our JavaScript like this: import { graphql } from 'graphql' … graphql(schema, query).then(result => { console.log(result); }) HTTP Background 19

📄 Page 20

HTTP is a format for sending messages over the internet. It is used on top of two other message formats—IP (which has an IP address and routes the message to the right machine) and TCP (which has a port number and resends any messages that are lost in transit). An HTTP message adds a method (like GET or POST ), a path (like /graphql ), headers (like the Bearer header we use for authentication), and a body (where GraphQL queries and responses go). When we enter a URL like http://graphql.guide/ into our browser, it goes through these steps: Browser asks DNS server what the IP address of graphql.guide is. DNS server responds with 104.27.191.39 . We can see for ourselves what the DNS server says using the nslookup command: $ nslookup graphql.guide Server: 8.8.4.4 Address: 8.8.4.4#53 Non-authoritative answer: Name: graphql.guide Address: 104.27.191.39 Browser sends out a message to the internet that looks like this: IP to 104.27.191.39 TCP to port 80 HTTP GET / Internet routers look at the IP part, see it is addressed to 104.27.191.39 , and pass it off to a router that is closer to 104.27.191.39 . The message arrives at 104.27.191.39 (the IP address of the Guide server), which opens the message, sees that it’s trying to connect to port 80, and passes the message to whatever server program (in this case, a Node.js process) is listening at the port. An IP address is the number ID of a computer on the internet, and we can think of a port as the number of a program running on that computer. The server process sees that the client wants to GET /, the root path, and sends back an index.html to the client. This sequence is a little simplified—it actually takes a separate round-trip message to set up the TCP connection, and for graphql.guide , the client is actually redirected to HTTPS at the beginning, which uses port 443 and sets up an SSL connection before sending HTTP GET /. Server The term server may refer to: 1. a computer connected to a network (usually the internet) 2. a process running on that computer that listens to one or more ports 3. the group of computers/processes that share the responsibility of handling requests In web development, servers are usually either static file servers (which serve files like our HTML, images, and JS bundle), application (app) servers (the ones that power our API and that the client talks to) or database servers. Server-side either means app servers or everything that’s not the client-side (including file, app, and database servers, as well as any other servers they talk to). Background 20