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

问题描述

背景：

我们有一个 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 接口。

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

解决方法

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