One powerful feature provided by next request. And next response is the ability to easily deal with cookies. The objective of a cookie is to store server determined data to the browser cookie store. The server sends the set cookie header to the browser as a part of the response. The browser then stores that cookie in its cookie store. The data is then automatically sent by the browser as a part of future requests to the same server. As a side note, in order to ensure that the value provided by the server does not get tampered by the client, you can sign the data on the server using a private key

and attach a signature as a part of the payload. And when later on the client sends the data back, you can verify the signature using the server private key to ensure that it hasn't been tampered with the theory of cookies out of the way. Let's take a look at a practical example of writing and reading cookies. Using next year's route handlers, we create a route called login and we plan to use the next response. In order to set a cookie, we expose a simple get handler, we create a next response with the payload message success, and then we use the response cookies member to set an off cookie to the value John Doe.

Finally, we return this next response object similar to how we are setting a cookie. In the login, we will create a logout route where we will delete the cookie. Instead. For this, we use the response cookies, delete method, and then same as before we return the response with the set and the delete mutation methods out of the way, let's take a look at how we can read a cookie on the server using the incoming next request. Within a route, who am I? We accept the incoming request and then we use the request cookies member to read any cookie that might be a part

of the incoming headers. Here we are reading the Oath cookie, which is the value that we previously set and deleted, and if that cookie exists, we will use its value, otherwise we will use the string anonymous. Finally, we return the resulting string as a part of our next response. Now let's build a simple client side application to interact with this htt PAPI. Within a simple next JS page, we start off with a simple use state to store the result of a, who am IAPI call next weekly, create a simple utility function that makes a fetch call to API slash who I,

and then stores the result into that who I state variable. We create another utility function called login that makes a fetch call to API slash login and then refreshes the value of who am I from the server. And finally, we create a utility function called logout, which makes a call to API slash logout. And once more, it refreshes who am I to load the initial value of who am I. We use Use Effect to simply invoke our utility function. We render out a simple UI that has a nice header, has two buttons, one for login, one for logout, along with a display of the current value of who am I,

and that's the entire client application. Let's demo its behavior within the browser. At the start of this page load, you can see that you are currently anonymous. You click the login button, which makes an API request To slash login. As a part of the response from the login API, you can see the header set cookie sent by the server with auth set to the value John Doe. The browser will take an action based on this set cookie header and within the application cookie section, you can see that for this domain, that cookie has been stored, this cookie will automatically become a part of feature requests from this client to the server.

For example, the next API call over here is Who am I? And within the request headers you can see that the browser sent that off cookie. The who am IAPI, that we coded reads that cookie on the server and returns it as a part of its response. And then within our frontend application, we display the result as a part of IUI. We can actually even make this API call in its own tab. And for any requests from this browser to that domain, the browser will attach that cookie and therefore the server can read that value and display it back as a part of its response. The other API we coded is logout, which deletes set cookie.

So if you make the request using the lockout button within the network tab for the logout request, we can see within the response headers set cookie auth set to empty with an expiry way back in the past in 1970. Based on this, the browser will delete the oath cookie from which cookie store, and therefore when the next request is made to who am I, the cookie will not be a part of the payload, and our server side code will return the string anonymous, which is what we display within the ui.