How Backend SDKs Work
Backend SDKs (Node, Go, Ruby, Python, Java, .NET, and other server runtimes)
authenticate with a backend SDK key (qf_sk_…), generated from the
SDK Keys page in the dashboard. For how it differs from the other
credentials — and why it must stay server-side — see
Keys & Credentials.
SDK Architecture
The Quonfig server-side SDKs are all built with the following 3 goals in mind:
- Very fast lookups that do not require any remote calls.
- Being highly resilient in the case of outages
- Near instant updates when changes are made
The architecture to do this looks like this:
Your code will instantiate a singleton of a Quonfig Client. This client starts will fetch the latest configuration, trying multiple sources in case of errors. Once it gets a connection it will unlock and be available for your code.
The client will also start a streaming connection to the APIs to pull down new changes.
The delivery service is split across two hosts: short-lived HTTP fetches go to
primary.quonfig.com and the long-lived SSE stream goes to
stream.primary.quonfig.com. The SDK derives the stream host from the
configured API URL (by prepending stream.) so you only configure one
apiUrls list and routing is automatic.
Additionally, the SDK will poll for updates as a resiliency measure.
Note that the evaluation is always happening in-process in your application. Feature flags and config are stored in process so are lightning fast (no API calls when you access them).
Implementation
When your client boots, it creates a local thread safe hashmap which will hold the config. The general purpose Quonfig config system will then push & pull changes down to your clients. The expected latency is < 100 ms.
Feature flags are built on top of the Quonfig config store so all reliability notes are applicable for Feature Flags as well.