我刚刚发现了feathersjs并且非常喜欢它背后的想法，尽管我仍然不确定基于服务的理念如何适合比简单的CRUD UI更复杂的应用程序。
为了更好地理解它，我做了一个例子：考虑一个可以创建和共享调查的应用程序。您可以轻松地设法创建调查服务，以创建，更新和获取调查的属性（即问题和答案）。但是如何处理以下方面：
1）有动作，即根本不影响数据的服务调用。一个操作可能是向尚未参与调查的所有受邀用户发送提醒电子邮件。如果不使用羽毛，我会为此创建一个专用的快速终点，但这些行为如何适合羽毛哲学？是否应该为每个操作创建一个服务（仅实现一个HTTP谓词）？这很快就会变得混乱。使用 hooks 检测虚拟字段的更新并触发操作？很难记录和混淆。
2）想象一下，用户可以在调查中添加评论。评论将成为调查模型的一部分（我将使用MongoDB，因此请考虑每个调查对象都有评论数组）。客户端Web将调用调查服务上的GET /survey/123方法，该方法将在其他属性（问题，答案，...）之间返回注释。但是添加评论怎么样？我应该使用专用服务，还是如何适应调查服务？这样的请求会是什么样的？
答案 0 :(得分：3)
来自Feathers slack频道：https://feathersjs.slack.com/messages/C0HJE6A65/
发送电子邮件很好。对于操作，您可以使用某个action属性执行修补程序，然后使用挂钩来确定应执行的操作等。另一种方法是只实现create的简单小服务。对于评论，我可能会提供comments或survey-comments服务，然后您的survey/123可以填充评论。或者网络可以进行2次调用，一次是获取调查，另一次是获取评论。