Moving Splits to a Service

Using a Service for Splits

Split lets you roll out features and experiment with a target group of customers across the full web stack: from deep in the backend to client-facing Javascript and mobile.

Feature flagging in mobile can be particularly advantageous. For example, consider what happens when a critical bug appears in a newly-released mobile feature: due to App Store approval delay, a fix can’t be delivered to customers in minutes; not to mention, you can't force customers to update their apps.

Many mobile and IoT apps are highly optimized for the resource constrained environment of the device. A feature flagging solution should have minimal or no significant impact on the size or performance of your mobile app.

A customer should be able to access a new feature whether using the web, mobile, or IoT app. A lack of consistency in customer experience can lead to customer frustration.

Split provides per-language libraries (.Net, Java, Node, PHP, Python, Ruby, Go) on the back end, JavaScript for browsers, and iOS and Android libraries for mobile. When we do not support a language, we recommend wrapping one of our server-side libraries in a small service - hosted on your infrastructure.

This same approach can provide benefits for your browser, mobile or IoT apps as well, querying the service at startup for which features are to be turned on and which are to be turned off. Let’s call it the 'phone home' approach.

This approach has a number of advantages:

Uniform experience: across devices, versions and viewports.

It ensures a uniformity of experience across clients. Since the web app can also query the same service, our customers can be confident that their customers will either see a feature on or off, regardless of how they access the product - via mobile or web. Thus, phoning home is portable.

Update your platform without touching the app

Split is a core piece of our customers’ infrastructure and is always improving. By hosting Split on the server-side, our customers can confidently upgrade their server-side Split library, without having to worry about older, possibly conflicting, versions of Split being used in older mobile or IoT apps. Phoning home avoids versioning headaches.

Use more data than available on the device or in the browser

When deciding whether a user sees a feature or not, you often need to leverage user data that may not be available on the device. Take, for instance, demographic data about the user or outputs of data models. Instead of downloading such sensitive data to the front end, you can simply pass the data to Split on the server side, thus bypassing the need to download and retain information on the browser or device.

No impact to file size

By hosting the library on server side, you need never worry about increasing the footprint of your mobile or IoT app by adding Split’s library. Phoning home is safe.

Best Practices for Designing the Service

The app should call home and retrieve a mapping of features to the treatment (aka variation, experience) to show the app user for those features. Assuming a service deployed at /splits, we recommend using the following REST API:

customer_id: a unique identifier for your customer. If your product has a web presence, this id should preferably be shared between web and mobile so that the customer will see the same treatment for a feature, whether they access it from the web or mobile app.

dimension_n_value: The mobile app can send any dimensions about the customer that the server should take into account while determining which treatment to show to that customer. For instance: current location, connection speed or device type of the customer.

Since dimension values are encoded in the query parameters, we recommend communicating over https.

Response Schema and Status Code

200 - this REST endpoint will always return a 200. In the case of failure, the 200 status code should be accompanied by an empty list as the response object.

The app should assume that if a feature was not returned in the list, then the control treatment should be shown. Control is a reserved treatment that indicates a problem in computing a treatment. When using Split, a developer should always handle control. For instance, here is sample Java code for a basic on/off feature:

String treatment = … // retrieved from the map returned by server
if (“on”.equals(treatment)) {
// feature is ‘on’. Turn it on for customer.
} else if (“off”.equals(treatment)) {
// feature is ‘off’. Turn it off for customer.
} else {
// feature is in ‘control’. Handle it either as
// ‘on’ or ‘off’ depending on your use case or
// provide any special handling.
}

If ‘control’ means ‘off’, we can simplify this sample code to:

if (“on”.equals(treatment)) {
// feature is ‘on’. Turn it on for customer.
} else {
// feature is ‘off’. Turn it off for customer.
}