Server Side Rendering and Feature Flag Management

CloudBees Feature Management has been offering Javascript SDKs for years. On one hand, rox-node can be used on the server side and, on the other, rox-browser is there for client-side, in-browser feature flags. While this covers many use cases, the limit between server and client is becoming fuzzier. React applications are no longer Single Page Applications running in the browser only. Everyone cares about SEO and Server Side Rendering (SSR) is becoming a standard. And if you use feature flags to show or hide some functionalities or data, SSR also makes sense from a security perspective: do not send to the browser data it’s not supposed to get! While doing SSR, you want the greatest amount of your code as possible to be shared between the server and the client. Obviously, having two separate SDKs makes this difficult. We are excited to introduce the rox-ssr SDK for CloudBees Feature Management that will simplify your logic. Simply use rox-ssr and it will do all the magic for you (see below). And because rox-ssr is written in TypeScript, you automatically get all the TypeScript definitions, allowing you to learn the CloudBees Feature Management API even faster and remain type-safe.

From a developer’s perspective, only rox-ssr is used. In the background, rox-ssr is automatically switching between rox-node and rox-browser depending on the environment. We know developers care about the size of their applications so we kept that in mind such that server-specific code is not bundled into your final client bundle. We successfully tested that with Webpack! We also know that developers care not only about the look and feel, but also performance. CloudBees Feature Management does not fetch flag values from its servers at every evaluation but instead fetches the flag configuration once and then uses it to evaluate the flags. Calling flag.isEnabled() is a local, constant-time operation. This was always true, rox-ssr makes it even better. On the server-side, rox-ssr will fetch that configuration and refresh it regularly. Rox-ssr allows you to directly pass this configuration to the browser, making the initialization of CloudBees Feature Management on the client side immediate: no delay due to fetching data from the CloudBees Feature Management server and no potentially annoying re-rendering of elements on the page due to flag configuration being received a few milliseconds too late. See this example below.

1. Register and create your new app on rollout.io

2. Initialize CloudBees Feature Management - this should be once on the server-side, once on the client-side

import

1. In your render() method, server-side, add a within the tag to send the CloudBees Feature Management configuration from the server to the clients:

import

1. Using the flags

featureFlags

  How to migrate from rox-node and/or rox-browser to rox-ssr   You might have had something like:

let Rox = null

import {Rox} from 'rox-ssr'   There is a small change to apply when declaring new Flag / Configuration / Variant. Before: const Rox = require('rox-browser') export const container = { flag1: new Rox.Flag(true), configuration1: new Rox.Configuration(''), variant1: new Rox.Variant('', []) } After: import {Flag, Configuration, Variant} from 'rox-ssr'   export const container = { flag1: new Flag(true), configuration1: new Configuration(''), variant1: new Variant('', []) }   Add (or update) the way to send configuration data to clients: import {Rox} from 'rox-ssr'   // ... <script type='text/javascript' dangerouslySetInnerHTML={{__html: `window.rolloutData=${Rox.rolloutData};`}} />   Want to try CloudBees Feature Management? Check out the 14 day free trial.