Client vs. Server
The node-js-server-sdk and the accompanying docs are open source and hosted on github.
Get started in a few quick steps.
- Create a free account on statsig.com
- Install the SDK
- Initialize the SDK
- Fetch Feature Gates or Dynamic Configs
You could skip this for now, but you will need an SDK Key and some Feature Gates or Dynamic Configs to use with the SDK in just a minute.
Install the sdk using npm or yarn:
Initialize the SDK using a Server Secret Key from the statsig console:
initialize will perform a network request. After
initialize completes, virtually all SDK operations will be synchronous1--the SDK will fetch updates from Statsig in the background, independently of your API calls.
Now that your SDK is initialized, let's fetch a Feature Gate. Feature Gates can be used to create logic branches in code that can be rolled out to different users from the Statsig Console. Gates are always CLOSED or OFF (think
return false;) by default.
From this point on, all APIs will require you to specify the user associated with the request. For example, check a gate for a certain user like this:
Feature Gates can be very useful for simple on/off switches, or more advanced user targeting. But what if you want to return an entirely different configuration to different users? What if you want to be able to send a different set of strings to your client for different locales? Or a different list of products for a new market (or new user)? Enter Dynamic Configs. The API is very similar to Feature Gates, but you get an entire json object you can configure in the console. For example:
Checking a Dynamic Config is nearly identical to checking a gate:
You can then fetch typed Dynamic Config parameters (and provide a default value as a fallback):
We mentioned earlier that after calling
initialize most SDK APIs would run synchronously, so why are
The main reason is that older versions of the SDK might not know how to interpret new types of gate conditions. In such cases the SDK will make an asynchronous call to our servers to fetch the result of a check. This can be resolved by upgrading the SDK, and we will warn you if this happens.
If you have a logged in user, or a deterministic way to identify users, pass a userID with each sdk call. You should pass as much information as possible with each check: this will enable you to use more advanced gate and config conditions, like country level or OS/browser level checks.
You can use the SDK to log events associated with the user. These events will be used to power A/B testing metrics in the future, and will show up in the Statsig console under the "Dashboard" tab (coming soon!)
The value and metadata fields are optional.
For more information, see our SDK documentation on github.