CloudBees Rollout 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 Rollout 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 Rollout API even faster and remain type-safe.
rox-ssr in details
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 Rollout 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 Rollout on the client side immediate: no delay due to fetching data from the CloudBees Rollout 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.
How to use rox-ssr
- Register and create your new app on rollout.io
- Initialize CloudBees Rollout - this should be once on the server-side, once on the client-side
import {Flag, Rox} from 'rox-ssr'
export const featureFlags = {
myFirstFlag: new Flag(true),
mySecondFlag: new Flag(false),
}
Rox.register('myTestNamespace', featureFlags)
await Rox.setup(<YOUR API KEY>)
- In your
render()method, server-side, add a<script>within the<head>tag to send the Rollout configuration from the server to the clients:
import {Rox} from 'rox-ssr'
// ...
<script type='text/javascript' dangerouslySetInnerHTML={{__html:
`window.rolloutData = ${JSON.stringify(Rox.rolloutData)};`}} />
4) Using the flags
featureFlags.myFirstFlag.isEnabled()
How to migrate from rox-node and/or rox-browser to rox-ssr
You might have had something like:
let Rox = null
if (process.browser) {
Rox = require('rox-browser')
} else {
Rox = require('rox-node')
}
Replace it with:
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 Rollout? Check out the 14 day free trial.
Top comments (0)