nma*_*rko 14 api asynchronous playframework django-rest-framework
我一直在研究Play Framework作为帮助我构建简单API的可能候选者.然而,Django Rest Framework(DRF)似乎也是一个非常强大的竞争者.
据我所知,DRF并不像Play Framework那样宣传自己是异步(或非阻塞)框架,但我对这是否重要感兴趣.我一直在考虑的情况是通过Mandrill向用户发送电子邮件 - 我不希望我的API陷入困境,等待Mandrill API告诉它是否发送了电子邮件.
因此,我认为这个问题可以概括为:客户的观点是否有益于我使用异步/非阻塞框架(如Play over the DRF)构建API,或者我错过了这一点？
Kev*_*own 15
我是一个Django REST框架贡献者(和用户),所以我的观点偏向于此.
Django REST框架基于Django构建,Django是Web应用程序的同步框架.如果您已经在使用像Django这样的同步框架,那么拥有同步API就不是问题了.
现在,仅仅因为它是同步的,这并不意味着一次只能处理一个请求.大多数处理Django应用程序的Web服务器都可以处理多个请求,一些主题甚至可以在多个线程上异步执行.通常这实际上不是问题,因为您的Web服务器通常可以处理许多并发请求,即使其中一些是阻塞的.当你有很长的阻塞通话时,你通常不希望在API中完成 - 你应该将它委托给像Celery或Resque这样的后台工作人员.
这不仅仅适用于Django,许多相同的原则适用于其他同步框架,如Rails和ASP.NET MVC.如果您有长时间运行的请求,通常应该将工作委托给其他进程而不是阻止请求.在这些情况下使用202响应代码是很常见的.
现在,这并不一定意味着异步框架是无用的.在Node.js等运行时,大多数框架都异步处理请求.在这些语言中使用同步框架没有意义,因此大多数库都是异步构建的.
您的选择非常依赖于您已经使用的工具.
关于连接到您的应用程序的客户端，无论您的服务器是否使用异步/非阻塞 (ANB) 技术，都应该没有任何区别。但它可能会对您的应用程序可以处理的请求数量产生很大影响。
假设以下场景：检查 FB/Google/etc 访问令牌是否有效的请求，然后使用它来获取用户的社交资料，然后返回一些内容。
如果您在服务器中使用阻塞 http 客户端，则在 2 个 http 请求中的每一个期间，为该请求提供服务的线程可能会被阻塞很多时间什么都不做。如果您在发出 HTTP 请求并且响应返回时使用非阻塞 http 客户端（例如 Play 带来的客户端），则该线程可用于执行其他操作（例如：处理另一个请求的一部分）。
请注意，要解决这个“问题”，您不需要 ANB 框架，只需要一个 ANB http 客户端。因此，您应该更多地关注应用程序中的操作类型，并检查您选择的框架将如何处理它们。例如：如果您的应用程序几乎由 DB CRUD 操作组成，并且 DB 驱动程序正在阻塞（如 Java 中的 JDBC 和可能是 Django 使用的那些），那么框架是否异步实际上并不重要，您将阻塞最多该特定组件的时间。
在您的电子邮件示例中，Django+Celery 可能与 Play/Akka 一样好。