(upbeat music) - [Instructor] So to get started, let's get an overview of what Apollo Client State is. Now applications have state and that state can represent lots of different things. It can represent data that's stored on the server and we have a local copy of that data in our application that we're either displaying or able to work with and change and then ultimately pushing those changes up to the server.
Application state could be user session information such as which column I'm sorting on or what's my current filter value or what was the last page that I was looking at. When we go to manage our application state, we have to ask ourselves, is the state that we're managing something that's stored on the server or is it something that's only stored on the client? For example, let's say we have a collection of widgets. The widgets themselves are most likely the primary piece of data that our application is managing.
This type of data we would want to share with other users, so only storing the list of widgets locally, within our local client state, wouldn't really work all that well in terms of other users wanting to be able to see that same list of widgets. However, let's take data such as doing a sort. So I want to sort on the widget name column or I want to do a filter or I want to edit a particular widget. That type of information might only be useful for a particular user.
There's really no point in storing it on the server. Other users don't really care what column you might be sorting on, that's just something that you select while you're interacting with the application. So that type of data, instead of actually pushing it up to the server, can be stored locally in whatever client is being used to manage the application state. Now historically, in GraphQL systems, the only type of application state that was actually stored in the cache of the GraphQL framework was the actual data that was retrieved from the server.
Of course, this meant that the other type of application state, the local application state, had to be stored using other means. Perhaps maybe including something like Redux into the application and managing the local state in Redux while the GraphQL client would actually store all of the data that was pulled down from the GraphQL server. Well, with Apollo, we actually have the ability to store both the client and the server state together in the same Apollo client cache and we can use the same familiar GraphQL syntax to actually query that client state and we can even write queries that actually have part of the query going to the server and part of the query actually going to the client and combining those into single queries.
We can also do direct cache read and writes to make our updates. The ability to store all of our state in one place actually saves us a lot of time and hassle in terms of creating more complex project configurations where we're having to think about where different pieces of data are being stored, different pieces of data that from the perspective of the running application are really the same thing. The only thing different is, which parts of that data actually ultimately get persisted out to the server.
In order for Apollo to be able to connect to a GraphQL server, for the Apollo client to talk to the GraphQL server, we have something called a link configuration. The link configuration basically allows us to configure how the Apollo client will interact with other servers or other sources of data that it needs in order to be able to fulfill queries and things like that made by the application. Now, the default link that is typically used is the HttpLink.
The HttpLink is basically allowing us to do queries and mutations against a traditional HTTP-based web server, but it's a web server that knows how to read and parse and understand GraphQL as well as send back the appropriate responses to that GraphQL. To work with client state, though, we don't actually need to talk to the server. So what Apollo does is Apollo provides us additional functionality to enhance our link configuration that basically says, certain queries are only handled on the client so the client state link will handle it, so it doesn't actually make the request up to the server, it just updates the cache locally.
And then other queries actually need to go all the way to the server to be fulfilled and then of course the HttpLink handles those. So the question then becomes, how does Apollo know whether or not our query should go to the server or should be handled locally. We can specify which parts of the query go to the server and which are local based upon the use of the @client directive. On any field where we apply the @client directive, it will not go to the server to get the data, instead it will use the local data in the cache.
This allows us to now mix our queries together into larger queries and be able to pull that data from wherever it makes the most sense to be pulling it. To actually set up this client state, we're going to be using the apollo-link-state package and there's a withClientState function that will actually be used to produce for us the actual client state caching mechanism that we need and we'll insert it into the overall link configuration of the Apollo client so that the @client directive can be picked up in our query.