支持一种 API 协议转换插件

[IMBlues]

当前所有的插件逻辑都是考虑将远端数据拉取到本地，当远端数据量越大，完全同步的成本越高。很多时候，我们并不需要拉取数据，只需通过 API 将数据正确地暴露出去即可。

原来的数据暴露模型：

Remote data   ---- sync ---->   Local DB  ---- api ---->  User(SaaS、other systems)

新的一种数据暴露方式：

Remote data   ---- api ---->   Transformer(in memory)  ---- api ---->  User(SaaS、other systems)

我们仅针对用户当前的请求，转换成对应远端数据的 API 查询语句，而完全不存储任何数据。

带来的好处：

• 不再有大量的数据同步成本压力
• 数据存储安全性更高，只要保证请求到远端的链路安全
• 数据实时性更高，不会受到同步周期的影响

可能存在的问题：

• 用户管理 API 的可靠性将小于等于远端 API 的可靠性
• 远端数据提供的 API 并不能完全支持当前的查询需求，例如按照层级搜索组织树（当前依赖于 Local DB 的 mptt 树）
• 多一套需要维护的 API 实现，当开发新的 API 协议时，会有额外的负担

总的来说，协议转换插件非常适合远端 API 完善、同步数据量过大 & 时间过长的场景。和数据同步插件类似，协议转换插件也只能提供一种相对通用的开发工具，具体针对各个不同系统，需要定制性的额外开发。

[piglei]

感觉得看每类 API 需求具体占多少比例。假如“同步到本地”（及相关的按层级搜索等功能）确实是一种极少数人才需要的功能。那可以考虑默认使用文中的纯请求代理方式（Adapter 模式），仅在有确切需求的时候才开启“缓存模式”，拉到本地。“缓存模式”提供的 API 是普通 Adapter 模式的超集？

[IMBlues]

目前大多数都是简单的数据请求，“少数”场景需要复杂 API。
所以确实可以理解为 “同步存储” 是 “协议转换” 的超集，将 API 数据直接进行协议转换返回和存入 DB 的逻辑也非常类似，如果存在复杂的查询功能，一定程度上可以通过内存数据处理实现。

[piglei]

复杂查询我就不建议通过内存实现了，因为这里不好判断“度”在哪儿。还是考虑建立多种后端类型，各自支持不同操作，感觉简单粗暴好理解一点。