The Full Stack Developer Guide Developer Hub

Welcome to the Full Stack Developer Guide developer hub. You'll find comprehensive guides and documentation to help you start working with the Full Stack Developer Guide as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    

Content delivery networks

This topic explains the basics of a content delivery network and different strategies for handling caching with Full Stack.

The options below describe how to get the power of experimentation with the performance benefits of CDN caching. For more information on how to implement these options, please file a support ticket or leave feedback at the bottom of this page.

What is a CDN?

A content delivery network (CDN) is a system of distributed servers that delivers content based on user location rather than origin server location. This substantially decreases page load time, especially for websites with high traffic and a global reach. CDNs work by copying content to a network of globally-distributed servers. When a user requests a webpage, the CDN redirects the request from the originating site’s server to a server that is physically closer to the user and delivers the cached content from there. The CDN also communicates with origin servers to deliver content that has not been cached.

CDNs and dynamic content

A CDN can improve an application’s performance, but this can sometimes make integrating new services challenging. Typically, CDNs serve cached or saved content (rendered by the origin server) and do not allow for dynamic logic to execute at the edge. This can make it difficult to use a Full Stack SDK because bucketing each user and randomly assigning a variation requires server-side execution. When the majority of requests are handled and fulfilled by a CDN, the user's request never gets to the origin, preventing SDK logic from running.

Considerations for your site

It’s important to identify where caching becomes a blocker in your application. For example, if your site only caches static content (CSS or images) but all dynamic logic runs at the origin, you might not run into issues. However, it can be tricky when experimenting on parts of an application that are heavily cached. Before launching an experiment, there are a number of questions you should ask:

  • What content do you cache?
  • Do you cache static content?
  • Do you cache all content?
  • How often do requests hit the origin versus the CDN?
  • Do you have cache-busting logic in place today?
  • Is it possible to bypass the CDN?
  • What are the restraints of your CDN provider?

The answers to these questions will help you understand when and where to make the user-level decisions required to run an A/B test. If certain types of requests are handled dynamically—by your origin—you might assign variations when you handle dynamic requests. Be sure to discuss these questions with your Optimizely account team.

Common solutions

There are several possible solutions for using Full Stack with a CDN architecture.

1. Make decisions on the edge

One option for implementing Full Stack in CDN architectures is to have experimentation decisions happen at the edge of the CDN. This option requires installing the Full Stack SDK on a CDN in an environment where the CDN can execute code at the edge. Some technologies that allow executing code at the edge of a CDN include CloudFront, Lamba@Edge, and Cloudflare Workers. If your CDN does not support executing code at the edge, you can still use this approach by forwarding the request to a CDN that does.

  1. Verify that the CDN supports executing code at the edge. If it doesn’t, redirect the request to a CDN that does.

  2. In the CDN that supports executing code at the edge, install the Full Stack SDK to make experimentation decisions for the user and store the results of those decisions in a cookie and return the request to the original CDN.

  3. Forward the request to your origin server along with the cookie representing Optimizely's decisions.

  4. On your origin server, parse the Optimizely decision cookie and render the correct variation content based on the Optimizely decisions.

  5. On your CDN, configure the caching so that the CDN includes the value of the Optimizely decision cookie as an input into the caching rules. By ensuring the cache key includes the value of the Optimizely decision cookie, you will guarantee that the CDN caches the content appropriately for subsequent requests that would have the same value in the Optimizely decision cookie. Subsequent requests can be handled entirely by the first CDN once content is cached.

2. Make decisions on a separate decision service

Another option is to create a separate service for making experimentation decisions. This is a similar option to the one above except you use your own decision service rather than requiring the use of a CDN that supports executing code at the edge.

  1. For all request which don't have an Optimizely decision cookie, redirect the request to your decision service.

  2. In the decision service, install the Full Stack SDK to make experimentation decisions for the user and store the results of those decisions in a cookie and return the request back to the CDN.

  3. Forward the request to your origin server along with the cookie representing Optimizely's decisions.

  4. On your origin server, parse the Optimizely decision cookie and render the correct variation content based on the Optimizely decisions.

  5. On your CDN, configure the caching so that the CDN includes the value of the Optimizely decision cookie as an input into the caching rules. By ensuring the cache key includes the value of the Optimizely decision cookie, you will guarantee that the CDN caches the content appropriately for subsequent requests that would have the same value in the Optimizely decision cookie. Subsequent requests can be handled entirely by the CDN once content is cached.

3. Make decisions at your server origin

A third option for implementing Full Stack in CDN Architectures is to make experimentation and feature management decisions at the origin in your web application and configure the CDN to cache the appropriate content based on a decision cookie that represents the decisions made at your origin servers. This option should be possible to implement with any major CDN provider.

  1. For every request to the CDN that does not contain an Optimizely decision cookie, forward the request to your origin.

  2. Install a Full Stack SDK in your origin application servers. For every request, bucket the user for all experiments and store the results of those decisions in a cookie. Respond to the CDN with the Optimizely decision cookie set.

  3. Configure the CDN to cache content based on the contents of the cookie set in step 2. For requests sent to the CDN that have the Optimizely decision cookie set, we can return the cached content. For requests that do not have the optimizely decision cookie set, forward the request to your origin servers as in step 1.

Note

For all options, the cookie should have a time to live (TTL) or an expiration limit so that if an experiment is altered, users will see the effects within a reasonable timeframe.


Content delivery networks


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.