解析翻页设计的最佳实践和后端设计概要

缘起

在技术开发过程中，翻页操作的设计常常涉及到多种需求和技术考量。回顾最近的讨论和设计，我们可以得到一些关键观点和最佳实践。

BFF评审中的翻页问题

在Shopee的BFF评审会议中出现了翻页设计上的一些问题，其中包括遗漏了特定字段，以及分页方式选择的困惑。针对这些问题，提出了一种新的设计方案：

BE can always pass folllowing field to FE and ask FE to pass back + extra field (which is direction and limit) for next pagepagination: {
first_idx:{ctime, id}
last_idx:(ctime, id}
has_prev_element: bool
has_next_element: bool
}
this way FE can go first page, next page, prev page and check if has prev page & next page
this however wont support go to last page

这个方案的精妙之处在于它提供了一种相对简洁但非常有效的分页逻辑，并在前后端之间建立了一种互动方式，实现了基本的翻页需求。以下是这个方案的精妙之处：

1. 字段传递与双向交互：

   • 后端始终向前端传递特定字段，并期望前端传回额外字段（如方向和限制）以便进行下一页操作。这种字段的双向传递建立了一种有效的通信机制，确保了前后端在分页操作上的互动。

2. 清晰的分页信息结构：

   • 采用了清晰的分页结构，包括first_idx和last_idx字段，它们记录了当前页的首尾索引（以ctime和id表示）。同时还包含了has_prev_element和has_next_element布尔字段，用于指示是否存在前一页和后一页的元素。

3. 前端操作的灵活性：

   • 这个方案赋予了前端相对较多的操作自由度。前端可以根据first_idx和last_idx字段，自由地进行首页、下一页、上一页的操作，同时可以检查是否存在前一页和后一页的元素，以进行相应的页面按钮状态展示。

4. 简洁的设计与易于理解：

   • 这种设计相对简洁，同时也易于理解。通过明确定义的字段和指示，清晰地传达了分页的相关信息，使得前后端在交互时能够快速理解并实现相应的逻辑。

5. 不支持跳转到最后一页的合理性：

   • 即使这个方案不支持直接跳转到最后一页，但这个设计决策是合理的。因为通过记录当前页的首尾索引和是否有前后页元素，已经提供了基本的翻页操作所需的信息，从而满足了绝大多数情况下的用户需求。

总的来说，这个方案在提供基本分页需求的同时，设计简洁、清晰，并且建立了一种前后端之间相对有效的交互方式，使得用户能够方便地进行常见的翻页操作。

AuditLog翻页问题的处理

在另一个场景中，针对AuditLog的翻页设计也提出了一些解决方案，特别是在使用分布式数据库时，对于LIMIT操作可能导致的效率问题。针对这些情况，提出了使用自增主键作为游标的设计方式，以优化翻页操作的性能。

后端可以始终将特定字段传递给前端，并要求前端传回额外字段（如方向和限制），用于下一页的操作。这种设计支持前端进行首页、下一页、上一页的导航，并检查是否有前一页和后一页。

分页设计思考

在交流中，还涉及到了一些关于翻页设计的思考和解决方案的尝试。特别是对于用户需求中对于总数和最后一页的坚持，提出了两种解决方案。同时也提到了过滤功能的重要性，使用户可以更轻松地找到他们需要的记录，而不是完全依赖于分页功能。
对有海量数据的电商场景来说，分页设计，性能是关键

---

关键点总结

总结这些讨论和实践中的关键点：

• 灵活性与性能的平衡：设计翻页功能时，需要在用户体验和系统性能之间找到平衡点。
• 数据库优化：使用自增主键等方式优化翻页功能的性能，尤其是在分布式数据库场景下。
• 用户需求：理解和满足用户对翻页功能的实际需求，同时考虑用户操作习惯和便利性。（白话是产品经理提的需求，开发也要argue一下，有些性价比不高的功能，比如翻到最后一页，是可以在会上提出来消减或降低优先级的，减轻工作量又保持产品精简）

---

进一步思考

翻页本质上是一个有状态的服务，使用黑盒字符串传递方式类似于Session方案和Token方案之间的区别。

1. Session 方案：

   • Session 方案保持状态，服务器存储用户状态信息，并发送一个标识符（session ID）给客户端。客户端再次请求时，携带此标识符，服务器根据其获取相关状态信息。
   • 类似地，翻页利用黑盒字符串传递信息，后端能够根据该字符串重建状态，提供下一页所需信息。

2. Token 方案：

   • Token 方案是无状态认证机制，客户端携带令牌请求，服务器验证该令牌以授权。令牌通常不包含状态信息。
   • 翻页所采用的字符串传递方式类似于无状态传输，前端不解析字符串，原样传回给后端，后端根据此字符串提供下一页信息，不依赖于传输中的状态信息。

这种黑盒字符串传递方式使得翻页服务实现了一种无状态的前后端交互方式，类似于Token方案的无状态传输。这简化了通信流程，减少了服务器端保存状态信息的负担，同时降低了传输的复杂性。
所以，翻页设计，一是要无状态化，后端不能存储翻页位置信息，不然负担就大了，传递到前端让其返回是无状态化的思路之一；二是，这个传递过去的字符串，其实前端不必负责解析，因为前端主要负责展示数据和根据用户响应传递给后端翻页指示即可，翻页的正确性应该由后端保证，这套方案的好处是技术上实现最便利的前提下，将前后端职责划分的最清晰，方案中这点思考有泛化的价值。