Cookies At The Edge: Not A Baking Blog Post

I came across an interesting use case for edge compute the other day: cookie management at the edge. It probably won’t be super relevant to a ton of people, but it’s an interesting use case I wanted to share, nonetheless.

Brief Background About Cookies

When most people think of cookies, they picture delicious baked morsels. But we’re not here to talk about those (unfortunately). In the context of web development, cookies are one of the options web developers have to store data.

Cookies are awesome. Compared to some of the other options, they have a lot of advantages:

• Unlike storing data in memory, cookies can persist even after the environment is reset. On the frontend, this means they can withstand browser reloads and on the backend they can withstand service restarts or crashes.
• Unlike localStorage or sessionStorage, cookies can be accessed on the server-side. This can allow you to create personalized experiences for users based on their cookies. Cookies can also have an HttpOnly flag that protects them from Cross-Site Scripting (XSS) attacks.
• Unlike a database, cookies can also be access on the client-side (unless they have the HttpOnly attribute). This means there’s no need to make an HTTP request to re-fetch data you may already have.
• Cookies are stateless, so they work incredibly well for serverless environments because they can be handled the same across any number of serverless functions. This is great for scalability.

These characteristics make cookies a great choice for some things (and not so good for others). Today, the most common use cases for cookies are:

• Session management: Logins, shopping carts, game scores
• Personalization: User preferences, themes, and other settings
• Tracking: Recording and analyzing user behavior

As mentioned above, cookies can be accessed both on the server-side or the client-side. To interact with cookies, you basically have two options: HTTP headers on the server-side and client-side JavaScript to access the DOM.

If you already knew about cookies, you may recall that back in 2019, Apple implemented a feature in their Safari browser called Intelligent Tracking Prevention (ITP). It was a pretty major change in the way their browser handles cookies.

With ITP 2.1, all persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry.

They list a number of reasons for this change that mostly deal with privacy, security, and performance. The important takeaway is that if you, as a developer want sessions that last longer than a week, you can no longer rely on creating client-size cookies.

So how do frontend teams approach this going forward? Do we keep the logic on the client-side and just let cookies expire after seven days? Do we move that logic to the backend, potentially in a different codebase or programming language?

Edge Compute To The Rescue

I was recently reading about an Akamai customer that was dealing with this exact same conundrum.

They decided to pull the cookie manipulation logic out of the frontend, but instead of putting it all on their backend system, they abstracted it away to the edge.

“Black Friday and Cyber Monday are critical events for [CUSTOMER], and its website needs to use caching for several campaign pages. CDN technology allows [CUSTOMER]to provide consumers with a consistent user experience during campaigns, while EdgeWorkers manipulates cookies instead of the origin server.”

The benefits here were two-fold.

Firstly, the team responsible for managing and using cookies could completely own that part of the logic. They didn’t have to wait for changes to be implemented by the backend team because they could just push whatever changes they needed to some edge function the were responsible for. And it didn’t matter what the main server technology was, they could keep using the language they were familiar with, JavaScript.

Secondly, for the reasons mentioned above, these cookies needed to be set on the backend. By comparison, if you implement cookie management logic on your origin server, you are creating more work for that origin server to handle. By pushing jobs to edge servers, you can reduce some of the workload going to the origin, which can reduce costs, and/or improve performance and reliability for other critical processes.

Closing

I’m not sure that this example is going to be particularly relevant to a lot of folks as it’s a pretty niche issue that you probably don’t deal with on a regular basis. Regardless, I found it interesting and though I would share. It’s one of those bits of information I like to keep tucked away in case I need it some day.

This concept isn’t unique to Akamai, but if you are currently a customer or want to learn more about the practical side of things, I’d recommend checking out the EdgeWorkers documentation. There is a section specifically for working with their built-in cookies module.

Thank you so much for reading. If you liked this article, please share it, and if you want to know when I publish more articles, sign up for my newsletter or follow me on Twitter. Cheers!

Originally published on austingil.com.