- Optimizely X Full Stack
THIS ARTICLE WILL HELP YOU:
- Implement Optimizely X Full Stack if your stack relies on microservices
Choose the best option for implementing Optimizely X Full Stack in your SDK
If your stack is service-oriented or relies on microservices, there are some best practices and special considerations for implementing Optimizely X 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 article describes the advantages and disadvantages of each option.
Option 1: Use Optimizely as a service
In this approach, you would use Optimizely as a service by wrapping the SDK and interfacing with network endpoints.
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 the SDK as a service has higher latency than including it directly in your services (option 2).
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.
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.
The primary advantage of this option that it preserves near-zero 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.