这是在前端处理独特客户行为的好解决方案吗？

Question

背景：

我们有一个 CMS 前端 (Angular2+)，它为具有相同构建的所有客户端提供服务（每个租户都有自己唯一的 URL 来访问他们的页面，并使用存储在 DB 中的 URL-slug 进行映射）。如果足够通用，可以通过模块化布局或数据库标志轻松实现 UI 需求的处理，或者作为最后的手段使用自定义 CSS。

对于行为要求，到目前为止，我们一直使用无代码规则系统，我们可以将存储在数据库中的条件和操作组合起来，然后在前端执行。

但是，添加 非常 特定的行为比较困难，因为它通常由以下任一者实现：

A) 使用更多边缘情况扩展当前代码库，随着时间的推移将难以维护，或者

B) 为 CustomerA、CustomerB 等添加自定义代码，这些代码仅为特定客户加载。

选项 A 似乎错误，因为不能很好地缩放，所以我跳过了。 选项 B 仍然添加代码来维护，但可能是最佳候选。

建议：

使用选项 B，我的计划是设置包含客户特定代码的 Firebase 函数，同时确保函数遵循 Typescript 接口的参数和返回值。

示例： 假设我们正在计算价格。然后我可以做类似的事情：

let productData: IProductData = getProductData();
let priceResult: IPriceResult = null;
if (hasCustomPricingFn) {
    priceResult = await customPricingFirebaseFn(productData);
} else {
    priceResult = await standardPriceFn(productData);
}

每当用户进行更改时，都会不断调用此代码，假设最坏的情况是每个用户会话 1000 次。

优点：

• 可维护性 - 每个功能都独立维护，同时仍保存在同一个前端存储库中
• 可扩展性 - 每个函数都可以有自己独立的生命周期，函数的数量没有限制
• 安全 - 代码不能在本地被篡改
• 减少技术债务 - 如果客户离开，主项目中将没有共享遗留代码

缺点：

• 依赖 HTTP 请求 - 没有离线可用性
• 高使用配额
• 如果IProductData或IPriceResult发生变化，需要修复N个代码模块（相比选项A中的1），但至少有Typescript接口会产生错误。

这是一个好的解决方案吗？

Answer 1

通过开发插件架构解决了这个问题。插件在前端源代码中，但按需加载。