FAQ

I already have feature toggles in my database / configuration – why should I use featureflow?

Sure toggling features off and on is something we’ve all done in one way or another for a while, but going above and beyond that at scale is something that involves a number of specific challenges, challenges we have spent years here solving.
You could implement your own federated configuration servers, add monitoring, add design, build time, create a custom dashboard etc. or you could add a couple of lines of code and use featureflow – we’ve done the hard work.
Featureflow goes above and beyond simple feature management, giving you the control, targeting and feedback that your software needs to become safer, more manageable and ultimately better for your customers – you can focus on your product and how best to manage it.
Our unique combination of runtime api, highly available architecture and administration dashboard gives you the control you wish you had on your application and helps bring your developers, product owners, Dev ops and marketing teams closer together. In addition, it’s multi platform capability allows you to easily manage the same features across multiple projects and platforms simultaneously – that’s hard with just a configuration file.

Is it safe and secure?

When you use our server sdks, your features are evaluated on your server, you choose which information you wish to send to Featureflow – the information you send is stored and used as luseful lookup data to help create and define new audiences and rules for your features, if the data isn’t sent you can still set rules you just have to enter the details manually.

When using the client-side sdk you can send selective context information and let Featureflow evaluate the features for you ( we would suggest sending a hashed user id and some non-individually identifying values such as roles, tiers, location etc.) or you can go via your own servers – again choosing exactly what you wish to send, or not to send, to Featureflow.

We load the rules for your features into a cache on your servers when your application starts, so they are there to use when you need them. We have a globally distributed CDN courtesy of Amazon Web services and multiple levels of redundancy – in the unlikely case of an outage, your rules will be there on your servers. Our layers of redundency (in-short) look like this:

Multiple Availability Zones for database and servers

Featureflow Highly available and instantly scalable Server Cluster

Global CDN

Local SDK Caching on your servers

Programmed Failover

Is there a performance impact?

As the rules are evaluated on your servers, the performance impact is virtually zero. When using the client side sdk we use local browser or app database storage plus CDN caching to minimise impacts – it should be as quick or faster than a call to your own servers.

What if I don’t want to use it any more?

Every feature has a hard-coded absolute fail over value – you can set the correct failover values, stop using Featureflow and remove the code when you require.