Lesson 3: Work with Clients
What is a client?
A feature flag is not useful for anyone unless it's consumed. The consumer of this feature flag is not the end user of your product but rather a part of your application. We call this consumer a client. Most feature flagging systems support clients of both backend and frontend types, and most provide SDKs to easily integrate.
In Confidence, every SDK or API integration can be its own client, letting you control which flags are accessible from which part of your application. You add a Confidence client to your code to handle communication with the resolve API.
Best practices
There is no benefit to having multiple systems share a single client. Instead, treat every integration as its own client. This allows for a flexible and future proof approach where frontend clients (using the static paradigm) are not overwhelmed with all the flag data that is only relevant to backend clients.
In other words, by only letting one app access the flags that are relevant to it, you can reduce the overhead of having many flags in your systems.
Example: Manage latency with multiple clients
Consider this example: a single Confidence client is shared across 20 backend services and 3 frontend apps, covering 5 flags. Frontend clients evaluate all flags at startup — say 30 ms. Backend services evaluate one flag at a time. Now the backend team creates 100 new flags, all backend-only. Frontend clients still fetch data for all of them, inflating their startup latency for flags they'll never use. Separating clients per integration avoids this entirely — Confidence clients for frontend and backend stay scoped to their own flags.
Client granularity and security
It's good to have one client per app (backend service or frontend application). With this granularity, you can control the access of individual modules. For instance, you can revoke access to one backend service without stopping all of the others. A single client per app also helps you control what information is exposed to the user. Even if you don't expose all flags directly to the user, any information that reaches a frontend app can be considered exposed. For instance, if you have a flag intended for a backend service called 'enable super secret new feature X' and you use the same client for your frontend, that flag is still fetched and could be introspected by someone snooping around with a browser debugger.
In Confidence, each client authenticates separately with Confidence, giving you granular control to revoke access to individual modules without affecting others.
It's bad to have more than one client per app. Each client acts as its own universe. Multiple clients lead to multiple network requests to fetch flags and keep multiple copies of internal state such as context describing the module.