[RFC] 038 - Feature Flags

[arvinxx]

背景

我们有很多针对界面自定义的需求，主要在于需要隐藏部分界面功能，以满足不同场景的诉求

• 部分插件按钮是否可以隐藏？ #840
• [Request] 如何关闭DELL3这些服务。因为给企业内部使用。针对不同人群想限制一些功能 #1189
• [Request] 如何禁用默认的OPENAI #1748
• [Request] 是否可以加入禁止用户自己输入API的选项 #533

设计思路

在 LobeChat 中会计划添加两层 feature Flag 控制，一层在环境变量，一层考虑在中间件。先准备做到环境变量里

环境变量方案

实现语法复用之前 MODEL_LIST 那种， +abc 是开启某个功能，-abc 是关闭某个功能。多个配置之间通过 , 分割。

比如 FEATURE_FLAGS=+webrtc_sync,-openai_api_key 代表了开启 WebRTC 同步，隐藏 OpenAI API key

[arvinxx]

Feature Flag 简介

Feature Flag（也称为 Feature Toggle、Feature Switch、Feature Flipper 或 Feature Control）是一种软件开发实践，它允许开发团队动态地更改系统的某些功能，而无需修改代码。这种做法可以用于各种目的，例如渐进式发布、A/B 测试、灰度发布或处理运行时的功能开关。

Feature Flags 的工作原理是在软件代码中添加条件逻辑，该逻辑根据配置或数据库中的标志值决定是否启用某个功能。这种方式使得开发人员可以推出新功能而不立即对所有用户可见，也可以根据需要对特定用户群体或环境启用或禁用功能。

Feature Flags 的主要优点包括：

1. 快速迭代：Feature Flags 允许团队快速部署新功能，而无需长时间的测试周期，因为新功能可以默认关闭，并逐渐向用户展示。

2. 灵活的控制：团队可以根据业务需求或性能数据，动态地开启或关闭功能。

3. 降低风险：如果新功能出现问题，可以立即关闭该功能，而不需要回滚整个应用程序。

4. 渐进式发布：通过逐步向用户介绍新功能，可以更好地管理变更，并收集用户反馈，以优化功能。

5. 实验和测试：Feature Flags 使得进行 A/B 测试或其他用户体验实验变得更加容易，因为可以控制哪些用户看到哪些功能。

然而，Feature Flags 也有一些潜在的缺点：

1. 技术债务：如果不妥善管理，Feature Flags 可能会引入额外的复杂性，并在代码库中留下过时的标志。

2. 性能影响：过多的 Feature Flags 检查可能会影响应用程序的性能。

3. 管理挑战：需要有一种机制来跟踪和管理 Feature Flags 的状态，否则可能会导致混乱和错误。

4. 测试复杂性：每个 Feature Flag 可能需要单独测试，这可能会增加测试的复杂性和工作量。

为了有效地使用 Feature Flags，团队应该制定明确的策略和最佳实践来创建、部署、管理和退役这些标志。这通常涉及到使用专门的 Feature Flag 管理系统，这些系统提供了界面和工具来控制和监控 Feature Flags 的状态。

[cy948]

Feature Flags 的控制，我的想法是：

1. 环境变量层面：将控制 Feature 开关的方法或配置抽离为单独的配置文件，如 .lobechat.config.ts。该配置文件中可以对相关 Feature 的开关或依赖进行配置。优点：可以在一个文件中追溯到所有使用到 Feature Flag 功能的代码位置。
2. 中间件层面：若新 Feature 是后端实现功能，可以利用中间件对访问路径进行处理。如拦截用户对 GET /api/feature/example 的访问可以禁止用户对 Feature example 的使用。优点：灵活度高，配合后端数据库可以实现动态 Feature 访问管理。
3. 管理层面：中心化地维护一个 Feature 清单，根据用户选择的 channel 开放相应的功能。

[arvinxx]

关键实现整理

配置文件

src/config/featureFlags/index.ts ，在该配置中添加字段进行控制的字段：

export const FeatureFlagsSchema = z.object({
  webrtc_sync: z.boolean().optional(),

  language_model_settings: z.boolean().optional(),

  openai_api_key: z.boolean().optional(),
  openai_proxy_url: z.boolean().optional(),

  create_session: z.boolean().optional(),
  edit_agent: z.boolean().optional(),

  dalle: z.boolean().optional(),
});


export type IFeatureFlags = z.infer<typeof FeatureFlagsSchema>;

// 开关默认值
export const DEFAULT_FEATURE_FLAGS: IFeatureFlags = {
  // WebRTC 多端同步，计划在 1.0 中将此值改为 false
  webrtc_sync: true,

  language_model_settings: true,

  openai_api_key: true,
  openai_proxy_url: true,

  create_session: true,
  edit_agent: true,

  dalle: true,
};

// 将变量字段转换为在应用中进行判断的语义化变量名
export const mapFeatureFlagsEnvToState = (config: IFeatureFlags) => {
  return {
    enableWebrtc: config.webrtc_sync,
    isAgentEditable: config.edit_agent,

    showCreateSession: config.create_session,
    showLLM: config.language_model_settings,

    showOpenAIApiKey: config.openai_api_key,
    showOpenAIProxyUrl: config.openai_proxy_url,

    showDalle: config.dalle,
  };
};

服务端环境变量

在 src/config/server/featureFlags/index.ts 中解析 FEATURE_FLAGS 环境变量，得到加工后的 serverFeatureFlags 对象。

export const getServerFeatureFlagsValue = () => {
  const flags = parseFeatureFlag(env.FEATURE_FLAGS);

  return merge(DEFAULT_FEATURE_FLAGS, flags);
};

export const serverFeatureFlags = () => {
  const serverConfig = getServerFeatureFlagsValue();

  return mapFeatureFlagsEnvToState(serverConfig);
};

服务端环境变量传递到客户端

在 GlobalProvider 中实现服务端状态注入：

https://github.com/lobehub/lobe-chat/pull/2213/files#diff-ebfdeaa7cc0bfcd1e44c8c76356df27edf9c14ce98ccd13c8e6f2c4019848d2f

思想类似于 React Context 的用法。

客户端取值判断：

组件中使用 useFeatureFlagStore(featureFlagsSelectors) 获取当前的所有开关，基于开关进行判断。

const HeaderAction = memo(() => {

  const { isAgentEditable } = useFeatureFlagStore(featureFlagsSelectors);

  return (
    <>
      <ShareButton />

      {isAgentEditable && <SettingButton />}
    </>
  );
});

[arvinxx]

第二次在中间件（EdgeConfig） 的Feature Flag 实现：

• 🔨 chore: enhance EdgeConfig with per-user feature flags support #9541