前后端分离后的前端更应该当作一个独立的应用程序，而不是某个大产品的附属。如果再考虑离线和数据同步的情况，也可以说是一种分布式系统了。因此我觉得考虑是否分离的最大因素，就是前端是否复杂到了需要做成一个独立的应用程序。

本质上这是衡量软件复杂度和抽象的问题。一方面它取决于实际需求。比如 MVC 分层是 web 框架最佳实践？做个简单的网站也许并不需要，Sinatra 那种在 block 里写实现的方式也许更快； jQuery 难以维护？如果你的需求只是网页上加少数动态组件可能它更简单。另一方面也在于开发者自身的技术背景。同样做个 SPA 在专业前端和顺带写点网页的后端眼里复杂度可能完全不同，因此做出的决策也不同，但结果可能殊途同归。

如果是仅仅是删除旧数据，为什么不用 SQL ？

1. 如果不是很老的 mac 基本可以放心。我 12 年的 macbook 用到去年，一直都是升级到最新的版本没问题。不过周围也有少数出意外的（基本是比我更老的），备份一次数据再做比较好。
2. 这是既定事实，无法改变。不如调整自己的心态接受。

作为软件开发者，我觉得不更新是没法接受的。这意味着没有新特性，bug 不会修复，并且迟早会被抛弃。

不升级的理由是什么？

对每个 order 而言，找它的 package 的数量和状态为 4 的 package 的数量相等的就行了。

SELECT o.*
FROM orders o
JOIN packages p ON p.order_id = o.id
WHERE o.state = 4
GROUP BY o.id
HAVING COUNT(p.id) = SUM(IF(p.state = 4, 1, 0))
;

为了更贴近 SQL 标准（也方便以后弃坑 MySQL），把 if 换成 case 更好：SUM(CASE WHEN p.state = 4 THEN 1 ELSE 0 END) 。算是补充炮哥言简意赅的回答吧。

分两套，说下原因：

1. API 并不是把原本渲染网页的 controller 数据改成渲染 JSON 就完了，它的职责更加单一化
2. 如果主要逻辑在 service object (model 也行) 里，controller 分开很简单。把 controller 想像成处理 HTTP 接口的层就行。

应用层面的唯一性验证因为 race condition 不能完全保证数据唯一（虽然大部分情况下够用）。下面的链接跟 Rails 无关，不过足以解释你的问题：

https://hexdocs.pm/ecto/Ecto.Changeset.html#unsafe_validate_unique/4 https://hexdocs.pm/ecto/Ecto.Changeset.html#unique_constraint/3

转眼都 5 了……

支持 JSON:API 规范的库里 AMS 一直都是速度垫底的，也不是功能最强大的。

这是一个冷知识。虽然看起来不可思议，但确实可以，见 Implicit Array Assignment

a = 1, 2, 3

p a # prints [1, 2, 3]

不过谁真在项目里这么写肯定拉出去砍了。太不直观，容易误读。