We’ve been using Statsig for the past four months across different surfaces: www.statsig.com, our main landing page, console.statsig.com, our main web interface for using Statsig as a tool, and in some internal tools we’ve built for ourselves. Coming from Facebook, it was natural for us to use Feature Gates to “gate off” features under development, Dynamic Configs to decouple configurations from front-end code, and Experiments+ to start optimizing our conversion funnel. We use all of these and more every day. But where did we get started? …
Background: This post assumes some prior knowledge of Statsig Feature Gates (Feature flags). You can read more in our article: What are Feature Flags?
To evaluate Feature Gates on your servers or in your clients, Statsig provides SDKs in a number of different languages. Let’s explore how they work.
Statsig SDKs target two different types of environments:
All SDKs expose a similar API:
Note: this posts assumes some prior knowledge of feature flags and how they can help with modern software development. If you’re already sold, and just want to learn a bit more about how they work, read on! At Statsig, we call them “Feature Gates” — they act as a gatekeeper to new features. I’ll refer to them as such for the remainder of this post.
At a high level, feature gate evaluation goes like this: a developer wants to know if a user is eligible for a certain feature, so they check that user against the Feature Gate they created…
Anyone doing Android development in 2021 and beyond should strongly consider using Kotlin. Here are a few of the key features and reasons we chose to use Kotlin: