用户频繁进行增量修改时如何避免持续触发数据库更新操作

前端层请求合并 #

• 对拖拽触发的更新逻辑加300~500ms防抖，仅在用户停止拖拽操作后才发起更新请求，避免拖拽过程中每移动一个位置就触发一次接口调用
• 连续调整多个任务排序的场景，可额外叠加1s窗口的节流逻辑，收集窗口内所有排序变更后统一提交

// 防抖提交示例
import { debounce } from 'lodash';
import { API } from 'aws-amplify';
import { batchUpdateTodoSort } from './graphql/mutations';

// 拖拽结束时触发该方法
const handleSortChange = debounce(async (sortedTodos) => {
  await API.graphql({
    query: batchUpdateTodoSort,
    variables: { todos: sortedTodos.map(item => ({id: item.id, sortOrder: item.sortOrder})) }
  })
}, 400)

排序字段设计优化 #

• 放弃连续整数作为排序值的设计，改为初始赋值时间隔100/1000的数值（如100、200、300），拖拽插入时仅需修改被移动任务的排序值为前后两个任务排序值的中间值即可，不需要批量修改其他所有任务的排序字段，单条更新即可完成排序修改，大幅降低写入数据量
• 当数值区间被占满时，再触发一次全量排序值重置即可，这类场景出现频率极低，对用户无感知

DynamoDB + GraphQL 层优化 #

• 不要使用单条updateTodo mutation逐一更新任务，在Amplify Schema中定义批量更新mutation，直接映射DynamoDB的BatchWriteItem能力，单次请求即可完成所有变更写入，DynamoDB单批次最多支持25条写入，完全覆盖普通待办列表的量级

# amplify/backend/api/[your-api-name]/schema.graphql
type Todo @model {
  id: ID!
  content: String!
  sortOrder: Float!
}

input TodoSortUpdateInput {
  id: ID!
  sortOrder: Float!
}

type Mutation {
  batchUpdateTodoSort(todos: [TodoSortUpdateInput]!): [Todo]
}

• 为batchUpdateTodoSort配置DynamoDB原生resolver，不需要额外Lambda中转，进一步降低请求延迟和运行成本

体验优化 #

• 拖拽完成后先更新前端本地状态渲染最新排序，无需等待接口返回结果，避免操作卡顿；接口请求失败时做轻量提示并回滚状态即可，待办类场景对一致性要求不高，最终一致即可满足需求
• 多端同时修改的场景可加乐观锁校验，通过version字段判断冲突，冲突时提示用户合并即可

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