Local Personalizations

Unless you are running a complete brochureware site, chance are, you have some sort of content personalization requirement, whether it’s user’s name, number of items in the shopping cart, custom navigation or something entirely different, specific to a particular user.

Let’s examine a prototype of a standard e-commerce personalization logic.

When a user logs in, on success, we store their identifier in a session variable (commonly — browser cookie). When that user navigates to a different page, we retrieve user information (to acquire first name to display) based on the identifier stored in a local cookie and then, if the user exists, we pull user’s shopping cart information to display a number and, in this case, amount of items in the cart.

From a code perspective, the logic is pretty simple. You add a few line snippet of code to your header and on every page you now display information personal to that particular user. Easy.

var loggedUser := user.New(cookie)
if len(loggedUser.firstName) > 0 {
  loggedUser.fillShoppingCart()
}

But the ease of implementation comes at a cost of a performance hit. First of, we just added two new lookups to every page. Furthermore, because every page is now a page that has dynamic content, pages cannot be easily cached. Which, in turn, means that every page you serve will always need to perform multiple lookups to retrieve the information needed to be custom for that individual user. Which sucks.

Note, the lookup implementation logic for both user and shopping cart information can vary. Most commonly, those calls query the database for the data. Information can also be retrieved from APIs (both internal and third-party), which, given JavaScript AJAX lookup ability, can be done completely in the front end code, partially solving “no caching” issue. However, API lookups come with a set of additional performance challenges that need to be considered.

Luckily, in a lot of cases, those lookups can be minimized, if not eliminated altogether.

Store all the information you need in cookies.

That’s it. For the example above, in addition to storing user id in cookies, also store user’s first name. And update cart counter (and maybe an amount) cookie every time the user updates the cart. This way, instead of doing server lookups, the information will be available directly in user’s browser.

There, of course, may be a reasonable concern about data tempering. Since browser cookies can be altered by a user, a concern would be that shopping cart data can be manipulated to rig the checkout process. An important thing to remember, the actual shopping cart page doesn’t have to (nor is recommended to) rely on the cookie for item information. This solution is intended to reduce the number of request calls that would’ve been made by every page. A database or an API lookup on a single page is not a problem we’re solving. Or should really be trying to solve in this case. Checkout process is one of the areas where a small performance hit is worth the data immutability guarantee.