AEM查找用例设计方案选型探讨

用例背景 #

• DAM中存有含10个预定义列的Excel文件
• 行数为3000-10000，当前及未来无PI、SPI数据
• 需在页面展示终端用户搜索词匹配Excel A列的结果，未来可扩展至匹配A+C+D列
• 此类搜索场景与AEM典型搜索（依赖Search API、索引优化等）不匹配

现有方案对比 #

方案一：客户端全量缓存搜索 #

实现步骤

• 开发查找组件
• 绑定基于资源的Servlet到组件资源
• 服务器端（Servlet）读取全量Excel并生成JSON
• 在Dispatcher缓存完整JSON
• 后续请求从缓存获取，Excel发布时触发缓存失效
• 客户端持有全量JSON并实现搜索逻辑展示结果

优缺点

• 优点：性能高效，大幅减少服务器请求，客户端内存中实现即时搜索，用户体验流畅
• 缺点：搜索逻辑分散在前端，未来若需关联JCR查询，需在客户端处理全量数据集，复杂度高；前端无法主动感知后端数据更新，需额外机制处理缓存失效后的DOM同步

方案二：服务器端搜索+按搜索词缓存 #

实现步骤

• 开发查找组件
• 绑定基于资源的Servlet到组件资源
• 服务器端（Servlet）读取全量Excel，实现搜索逻辑并生成结果JSON
• 在Dispatcher以搜索词为选择器缓存JSON
• 相同搜索词请求直接返回缓存结果，新搜索词请求命中AEM Publisher
• 前端JS仅负责获取结果JSON并展示

优缺点

• 优点：搜索逻辑集中在服务器端，安全性更高，数据转换逻辑统一维护；后续扩展关联JCR查询更方便
• 缺点：每次新搜索都需请求服务器，性能较低，服务器请求量较大；若不做异步处理，每次搜索需刷新页面，用户体验差

优先方案选择 #

优先选择方案一，理由如下：

1. 数据规模在3000-10000行，转换为JSON后体积可控（按每行10个字段、平均每个字段10字符计算，10000行约1MB左右），不会对客户端内存造成过大压力
2. 客户端即时搜索的用户体验远优于服务器端搜索的等待/刷新流程，符合终端用户的使用预期
3. 关于后端数据更新的问题，可通过以下方式解决：
   • 在组件初始化时记录当前JSON的版本标识（比如Excel的最后修改时间戳），前端定时轮询接口获取最新版本标识，若不一致则重新拉取全量JSON更新DOM
   • 结合WebSocket实现服务器主动推送更新通知，触发前端重新加载数据

更优设计建议 #

针对方案一的不足，可优化为客户端缓存+服务器端版本校验的混合方案：

1. 服务器端Servlet返回全量JSON时，附带Excel的最后修改时间戳作为版本标识
2. 前端首次加载后将全量JSON和版本标识缓存到localStorage
3. 前端每次页面初始化或定时发起轻量请求校验版本，若后端版本更新，则重新拉取全量JSON并更新缓存和DOM
4. 若未来需要关联JCR查询，可新增一个服务器端聚合接口，接收搜索词后同时查询Excel数据和JCR数据，合并结果返回给前端；此时前端仅需调用该接口，无需处理全量数据集

另外，若担心前端搜索逻辑的主线程阻塞问题，可以将搜索逻辑封装为Web Worker，既保持客户端搜索的性能，又避免页面卡顿。

内容的提问来源于stack exchange，提问作者Som Mookerjee