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    


If your stack is service-oriented or relies on microservices, there are some best practices and special considerations for implementing Full Stack that you should understand.

Service-oriented sites have two implementation options: use Optimizely as a service or include the Optimizely SDK in every service. This topic describes the advantages and disadvantages of each option.

Option 1: Use Optimizely as a service

If your stack is service oriented and you would benefit from a centralized decision service, we highly recommend using Optimizely Agent, an Optimizely developed open-source service running the Go SDK in a docker container with custom configuration options. Optimizely Agent exposes HTTP endpoints that map to all the Full Stack SDK functions.

This approach has the advantage of centralizing challenging tasks like datafile management and event dispatching. You implement those solutions one time, and your team doesn’t need to worry about them when they start testing. Handling the datafile and event dispatches to Optimizely in only one place reduces the overall setup and maintenance effort.

The disadvantage of this approach is that a network call is required to determine whether to activate an experiment or to grant a user access to a feature. Communicating with Optimizely Agent has higher latency than using a Full Stack SDK directly in your service(s).

Option 2: Install the Optimizely SDK in each of your core services

In this approach, you would include instances of the Optimizely SDK in every service and rely on the deterministic and stateless nature of the SDKs to show users the same experience throughout each service. If you choose this option, you need to synchronize datafiles across all instances of the SDKs.

The primary advantage of this option that it preserves microsecond-latency decisions by the SDK. It is more performant than option 1 because all the decisions are made in memory without the need for a network call to a service. This option is also more configurable: each team sets up the SDK as best fits their implementation.

The disadvantage of this option is that teams must implement their SDK themselves, and maintenance costs increase. For example, if Optimizely releases a new SDK, you’ll need to update the SDK in every service where you have it installed.


Although this approach requires synchronizing the datafile across your services, most customers find that they don’t need to enforce exact synchronization everywhere. As long as each implementation has a relatively short cache expiration, occasional brief discrepancies are okay.

Updated about a year ago


Suggested Edits are limited on API Reference Pages

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