![Client-Side GraphQL in React](https://static.frontendmasters.com/assets/courses/2019-12-03-client-graphql-react/thumb.webp)
Check out a free preview of the full Client-Side GraphQL in React course
The "Storing API Data" Lesson is part of the full, Client-Side GraphQL in React course featured in this preview video. Here's what you'd learn in this lesson:
Scott explains that every node or object that gets returned from the API is stored in a local cache by ID and typename. It is considered best practice to save nodes using the default ID.
Transcript from the "Storing API Data" Lesson
[00:00:00]
>> Scott Moss: So, storing data from your API. By default, Apollo's going to store all the nodes, and when I talk about nodes, I'm talking about pretty much every object that's returned from a graph to API. Apollo is going to store those flat. And it's gonna be normalized, and it's gonna be flat inside of a local cache.
[00:00:23]
And we're gonna look at that cache, you're gonna see what we're talking about. And it does that by generating that unique ID. That unique ID is default to .id property, or ._id from your nodes. So basically if you look at, I think characters have an ID here, right?
[00:00:39]
So if we did ID, by default, Apollo's gonna look at an ID field or an _ID field on any single node. And that is gonna use that along with the, I believe it also uses typename.
>> Scott Moss: It's gonna use ID and typename combined to create a unique Index for each individual note, and he's going to store them flat inside of a local cache and memory.
[00:01:07]
So what does that mean flat will, right now if you look at this architecture right here, this data model, it's nested, you have characters and results and the results is an array of all these. Well, Apollo is going to start them all on the top level every single one of these items is going to be stored flat in the keys going to be like their ID plus their type name or something like that.
[00:01:27]
And that's how they're gonna be stored by default. That's what happens. So, it's a really good habit of making sure you always return an id or a _id from every single query that you do. Otherwise, you are going to have to change what Apollo stores as far as the ID, which you can.
[00:01:46]
There's a function in Apollo you can see that you can override, like you know what, don't use ID. Run this function to compute the ID for all my nodes. But my recommendation is, always send on an id, or an _id, or none at all. It's not a good practice to say, these nodes have IDs but these nodes don't, like I would not do it just make sure they all have IDs or none of them do.
[00:02:09]
And if none of them do, then you need to write a function to let Apollo know how to generate a unique ID to store these things.
>> Scott Moss: Any questions on that?
>> Speaker 2: So that means that yesterday we talked a bit about how you could get friends, of friends, of friends, of friends, of friends, of friends, of friends.
[00:02:27]
That data structure that's returned from your server, it's gonna be nested pretty deeply when you get it back in the results, but then with the client you can just say it can be friend with ID five. And it's gonna bind that in the structure and-
>> Scott Moss: So yes.
[00:02:40]
If you wanted to query from the clients ichache and you say, I wanna find this friend With this ID of five, yeah that would be possible because it's all stored flat. But it's not as simple as asking Apollo for give me this frame with this ID of five as you'll see.
[00:02:58]
It is that simple, but it's not that simple. [LAUGH] Basically you can do it, but there's a better way. But yes, it is very possible to do that.
>> Speaker 2: Yeah, my question was do all objects get rolled up to the top, like the next two topics as well?
[00:03:14]
>> Scott Moss: Yep. All nodes get rolled up the top, anything that's pretty much an object gets, it's all flat. There's no nested structure inside of this side of the pile of cache. And the reason they do that as we get more into it is, it allows you to easily update your cache when nodes get updated from different operations.
[00:03:39]
Like if you do a query that's getting all these characters.
>> Scott Moss: There you go. If you do a query getting all of these characters. But then you have another query that's slightly different, but gets characters as well. And then you have mutation that, I don't know, updates one of those characters, if they were stored the way that they came back nested.
[00:04:03]
You have to go into places and find that character updated. But if it was stored flat, there's only one instance of a character cuz it's a unique ID and it gets updated once. And both instances of those queries now have the new updated character, whenever you show them on the page.
[00:04:18]
>> Speaker 2: But if character has something like an address and address itself is an object, will that be rolled up again because then you'll have to maintain a reference between the addresses and their characters as well.
>> Scott Moss: So, that doesn't maintain the reference. In fact, what it does is it doesn't care about the references, and this is where operation names come in.
[00:04:36]
So, what it will do instead is, yes anything that's a node like an object type, or anything like that does get pushed to the top no matter how deep it is. And as far as references go, it doesn't really care about them cuz it remembers your query. So you can think about it like this, these operation names these queries.
[00:04:52]
These are index, so it knows what queries have access to what, and when a node gets updated via either you doing it automatically or you doing it manually, that query has the ability to just automatically update. Because everything inside of that query or one thing inside that query got updated via whatever you did a mutation or whatever.
[00:05:18]
So, it all happens automatically by default, unless you get to the point where, you have a mutation that's returning different fields than the query before it was returning. Then you manually have to do it. A lot of this sound's complicated, cuz I'm trying not to talk a lot about it, cuz we're gonna get to it.
[00:05:36]
But, yeah, there is a point where you will have to do some manual stuff. But most of the time, it's gonna be automatic. And Apollo doesn't care about relationships cuz it doesn't have to. It just remembers query operations and it stores everything flat. Because that's the only way you can access data is through a query operation.
[00:05:54]
That's what your components are concerned about. Your components aren't even concerned about relations. So, those relations mean nothing to Apollo. And when we go to the cache and explore it, you'll see what I'm talking about. You'll see how all that stuff works.
Learn Straight from the Experts Who Shape the Modern Web
- In-depth Courses
- Industry Leading Experts
- Learning Paths
- Live Interactive Workshops