Data Masking in GraphQL Clients

class: center, middle

# Data Masking in GraphQL Clients

## Rob Richard
## Director, Front-End Engineering @ 1stdibs

???

* Hi! My name is Rob and I'm a Front-End Engineering @ 1stdibs.

---

???
* 1stdibs is an online marketplace for rare and desireable goods. We sell Vintage and Antique Furniture, Jewelry, Fashion, and Art.
* Our front-end team is all-in on JavaScript. 
* Our stack is Node, GraphQL, React, & Relay.

---

# Data Masking in GraphQL Clients
* Data masking is a unique feature supported in Relay
* First a brief overview of the Relay API

???
* Today I'm going to talk about Data Masking in GraphQL Clients
* I know that Apollo tends to be a more popular choice when it comes to GraphQL Clients.
* So I wanted to go more in depth on this feature that is unique to Relay and I think is very underrated.
* But first a quick overview of the Relay API

---

# Relay API `<QueryRenderer/>`

```jsx
const MyComponent => (
  <QueryRenderer
    query={graphql`
      query MyComponentQuery($personId: ID!) {
        person(id: $personId) {
          id
          name
          height
          homeworld {
            id
            name
          }
        }
      }
    `}
    variables={{personId: "xlOjM="}}
    render={({props}) => {
      if (!props) {
        return <div>Loading</div>;
      }
      return (
        <div>
          <h1>{props.person.name}</h1>
          <div>height: {props.person.height}</div>
          <div>home world: {props.person.homeworld.name}</div>
        </div>
      );
    }}
  />
);

```

???

* QueryRenderer is a React Component provided by Relay that takes in a few props.
* Here's an example of the QueryRenderer using the Star Wars API.
* The first prop is a GraphQL query
* The second prop is the variables for that query
* This component will execute this query against your GraphQL server
* It has a `render` prop, which is called twice, first to render the loading state, and again with the response from your GraphQL server.
* This example is using a QueryRenderer to fetch and render all the data it needs

---
# `createFragmentContainer`

```javascript
const PersonComponent = ({person}) => (
  <div>
    <h1>{person.name}</h1>
    <div>height: {person.height}</div>
    <div>homeworld: {person.homeworld.name}</div>
  </div>
)

export default createFragmentContainer(PersonComponent, {
  person: graphql`
    fragment PersonComponent_person on Person {
      id
      name
      height
      homeworld {
        id
        name
      }
    }
  `
})
```

???
* Up next we have `createFragmentContainer`.
* `createFragmentContainer` is a function that creates a higher order component.
* These components are used as children of a QueryRenderer
* It provides a way to directly couple a GraphQL fragment to a component.
* This allows the component to define it's data dependency via the fragment

---
# Updated `<QueryRenderer/>`

```diff
const MyComponent => (
  <QueryRenderer
    query={graphql`
      query MyComponentQuery($personId: ID!) {
        person(id: $personId) {
+          ...PersonComponent_person
        }
      }
    `}
    variables={{personId: "xlOjM="}}
    render={({props}) => {
      if (!props) {
        return <div>Loading</div>;
      }
+      return <PersonComponent person={props.person} />;
    }}
  />
);
```

???
* Now I've updated this QueryRenderer to use that fragment container.
* We reference this fragment in the `QueryRenderer`'s query
* And we render this component in the `render` prop.
* We can also consume fragment containers from other fragment containers.

---
# Why use `createFragmentContainer`?
* Allows components to define their data requirements
* Components are reusable
* Data masking

???
* Why use `createFragmentContainer`? You could just write one big query that gets everything you need at the top of your app.
* We use fragment containers because they allow individual components to define their data requirements
* * It's a declarative way to describe the data you need
* It also allows components to be more reusable
* * You can drop the component you need into other places of your app without adjusting your data fetching
* * If you have a component that renders a `Person` object, you can use this component anywhere you wanted to render this type. All you would need to do is pass it a reference to a Person object. 
* `createFragmentContainer` also enables data masking

---
# What is data masking?

* Data masking prevents components from accessing data they did not specifically request
* Prevents implicit dependencies

???
* Data masking prevents components from accessing data they did not specifically request
* In other words, it prevents implicit dependencies
* Let's look at an example

---
# Data masking example

```diff
const PersonComponent = ({person}) => {
+ console.log(person.homeworld.name); // undefined!
  return (
    <div>
      <h1>{person.name}</h1>
      <div>height: {person.height}</div>
+     <PlanetComponent planet={person.homeworld} />
    </div>
  );
}

export default createFragmentContainer(PersonComponent, {
  person: graphql`
    fragment PersonComponent_person on Person {
      id
      height
      name
      homeworld {
+       ...PlanetComponent
      }
    }
  `
})

```
???
* I've created a new PlanetComponent and updated the PersonComponent to use it to render this person's homeworld.
* * The PlanetComponent will have it's own fragment and request whatever data it needs
* I have a console log in here to demostrate that the PersonComponent, even though it's a parent of the PlanetComponent, does not have access to the data requested by the PlanetComponent
* The data masking feature will prevent parent or sibling components from accessing fetched data that was not defined by their fragments.
* PersonComponent is decoupled from PlanetComponent. It only knows that it needs to pass a planet object to it as a prop.
* If the requirements ever change for PlanetComponent and it needs more planet data to render, no changes are required to the components that consume it.

---
# How is data masking implemented?

* There's a two step process to render GraphQL data
* Step 1 - The network response is "flattened" into a store
* Step 2 - Data to be rendered is "selected" out of the store

???
# How is data masking implemented?

* There's a two step process to render GraphQL data
* Step 1 - The network response is "flattened" into a store
* Step 2 - Data to be rendered is "selected" out of the store

---

# The network response is "flattened" into a store

.flex[

.column.bigCode[
### GraphQL Response
```json
{
  "data": {
    "person": {
      "id": "xlOjM=",
      "height": 96,
      "name": "R2-D2",
      "homeworld": {
        "id": "V0czo4",
        "name": "Naboo"
      }
    }
  }
}
```
]

.column-arrow[
→
]

.column.bigCode[
### Client Store
```json
{
  "xlOjM=": {
    "height": 96,
    "name": "R2-D2",
    "homeworld": {
      "__ref": "V0czo4"
    }
  },
  "V0czo4": {
    "name": "Naboo"
  }
}
```
]

]

???
* Each object returned by the graphql server is put into a "flattened" store object.
* The id returned by the graphql server is used as the key. If there were more objects in this response they would each be added as separate keys on the top level of this object.
* Nested objects can be referenced by their ID using the __ref property

---
# Selecting data out of the store

* A selector can be created from
* * An ID reference to an object
* * A GraphQL fragment

???
* A selector can be created from
* * An ID reference to an object
* * A GraphQL fragment

---
# Selecting data out of the store

.big.flex[

.column[
.addition.codeBorder[
### Client Store
```json
{
  "xlOjM=": {
    "height": 96,
    "name": "R2-D2",
    "homeworld": {
      "__ref":
        "V0czo4"
    }
  },
  "V0czo4": {
    "name": "Naboo"
  }
}
```
]
]

.column[
.plus[+]
]

.column[
.addition.codeBorder[
### ID
```json
"xlOjM"
```
]
]

.column[
.plus[+]
]

.column[
.addition.codeBorder[
### Fragment
```graphql
fragment on Person {
  id
  height
  name
}
```
]
]

]
.big.flex[.equals[=]]
.big.flex[
.column[
.addition.codeBorder[
### Result

```json
{
  id: "xlOjM=",
  height: 96,
  name: "R2-D2",
}
```
]
]
]
???
* Using a flattened store object, an ID reference, and the fragment, you could create a function that returns the correct data for a component.
* Only the correct fields will be returned even if additional data was fetched. 
* This is what `createFragmentContainer` does internally.
* It's implemented by getting the selected fields from the graphql fragment, and a recursive function that can follow the references in the store.
---

# Selecting data out of the store

.codeBorder[
### react-redux
```js
// create Higher Order Component
export default connect((state, props) => {
  const person = state.person[props.personId];
  return {
    id: person.id,
    height: person.height,
    name: person.name,
  };
})(PersonComponent)
```
]

.codeBorder.marginTop[
### react-relay
```js
// create Higher Order Component
export default createFragmentContainer(PersonComponent, {
  person: graphql`
    fragment PersonComponent_person on Person {
      id
      height
      name
    }
  `
});
```
]

???
* If you've used react-redux, it's a lot like the `connect` function. In redux you would write a function that would return the needed properties from your store. In Relay this can be generated automatically from the fragment data.

---
# Selecting data out of the store

.codeBorder[
### Implementation
```js
function createFragmentContainer(Component, fragments) {
  return function HOC(props) {
    let componentProps = {};
    for (const propName in fragments) {
      componentProps[prop] = selectDataFromStore(
        props[propName].id,
        fragments[propName]
      );
    }

return <Component {...props} {...componentProps} />;
  };
}
```
]

???
* Here is a simplified implementation of createFragmentContainer
* * For each fragment passed to `createFragmentContainer` we check for a prop with the same name passed in and select the correct data out of the store.
* * The selected data is passed to the component, overriding the props from the parent.

---
# Why data masking?
* Why is this good? It prevents implicit data dependencies
* Confidence to remove unused fields.
* Helps you ensure you are not over fetching.
* Especially useful when you have a team working on a large codebase.

???
* Why data masking? What's the point?
* Makes implicit data dependencies impossible
* Let's say you're refactoring a component and it no longer needs a field from your GraphQL server. You have complete confidence that it can be safely removed from the fragment without understanding the whole codebase.
* * This confidence is important. If you're not confident that removing something won't break anything, chances are you'll leave it around. 
* * If this happens a few times you could be accidentally overfetching and your app will not be as performant as it could be.
* This is definitely something that's useful when it's a team of engineers working on a larger codebase. You're most likely to run into these types of issues as different people are working on the same files.
* Lastly, everything is a trade-off. You should choose your GraphQL client depending on your team's needs.
* Maybe that is something that's easy to get started with or it's something that provides more constraints to bigger teams.

---
# That's all!
* https://www.1stdibs.com
* twitter: @rob_richard
* github: @robrichard

???
* That's all!
* Thank you so much!