我们有一个大型的Django应用程序，它具有将多种技术混合在一起的复杂前端。我们正在考虑进行大规模的重新设计，并希望避免以前的有机增长复杂性，即REST API中的许多手动更改跟踪和单个端点。
数据模型涵盖了十几个Django应用程序和PostgreSQL中的156个表。一些资源非常大，并且包含到其他较小资源的映射列表。例如，AirplaneRepair（一种描述要计划的操作的数据结构）包含硬件和人员要求，两者都与何时需要有关。
前端具有一些挑战当前体系结构的通用功能：
否则，主要是通过后端强制约束/一致性检查进行数据处理。
我们在Django中定义了所有模型。那些应该留下来。 ORM将它们映射到数据库上。
REST API应该由两个根部分组成
/api/v2/resources/应该为所有模型提供通用CRUD访问权限。应该使用JSON-Patch原理提供更新（即，仅使用diffs而不是整个JSON blob）
?fields=field1,field3,field5应该允许过滤返回的数据以仅返回请求的子字段?expand=field.children应该触发prefetch_related或其他方式来自动扩展模型中的关系并将其放置在返回的JSON中/api/v2/services/包含任何特定的RPC调用，这些调用会触发后端的复杂操作，而不会映射到资源上。前端基于静态“框架”的组合，并对这些框架内的组件进行反应。我们使用react-redux来跟踪数据。通读this discussion on reddit，似乎其他人已经尝试将json-patch文档和redux / react结合起来。通常，redux的操作/减少器模式应允许轻松实现上述一些概念。