Feathers: 使 Feathers 服务器框架独立于 Express、Koa 和 Hapi

我认为最大的障碍是身份验证，特别是我们如何访问请求和响应对象以及护照中间件如何与 Koa 一起工作等。

快速浏览一下，Koa 看起来并不算太糟糕。 我们只需要使用https://github.com/rkusa/koa-passport-example和ctx而不是req和res 。 对于 Hapi，我不太确定，但我不相信支持 Hapi 有很多价值，它并没有真正提供与 Express 不同的任何东西。 至少在 Koa 中你有生成器支持。

恕我直言，如果我们希望更加灵活并且不依赖于框架，我们可能最好只使用独立模块进行路由、内容协商等。

对于 Koa 的套接字支持，我们使用此作为灵感： https://github.com/koajs/koa.io。

恕我直言，如果我们希望更加灵活并且不依赖于框架，我们可能最好只使用独立模块进行路由、内容协商等。

http-framework ！ ：眨眼：

@ahdinosaur ya，恕我直言，这看起来更像是正确的方法。

我认为我们应该让 Feathers 成为一个库而不是一个框架——这也将使它更加独立于传输。

例子：

通用代码

const feathersApp = feathers().configure(rest());
feathersApp.service('todos', new NeDB('todos'));
export default feathersApp;

特定于框架

考阿

import feathersApp from './feathersApp';
import Koa from 'koa';
import adapter from 'feathers-koa';

const app = new Koa();
app.use(adapter(feathersApp));

表达

import feathersApp from './feathersApp';
import express from 'express';
import adapter from 'feathers-express';

const app = express();
app.use(adapter(feathersApp));

基本上，适配器将为其特定框架创建中间件。

注： https ://github.com/spirit-js/spirit

@daffl我刚刚检查了精神，它看起来很整洁。 将羽毛与快递分离会很棒。 随着许多不同于 express 的新实现的兴起，它将使羽毛在未来更加强大。 对此有何决定？

这个身份验证 PR https://github.com/feathersjs/feathers-authentication/pull/336应该是我们需要的唯一主要部分，以便能够支持下面的不同框架。

在过去的几天里，我一直在考虑这个问题，现在我们即将结束 Auk，这将成为 Buzzard 版本的主要目标。 就像模块化查看使用数字一样好，Express 不会去任何地方。 去年它有 7000 万次下载，Koa 以140 万次下载，Hapi 以约 240 万次下载。

_我认为这些数字可能会被构建系统、部署频率、部署规模等人为夸大，但这可以大致了解事物的流行程度。_

老实说，看看这些数字，除了表达之外，真的没有太多的动力去支持任何东西。 我看到的主要原因是：

• http2 支持（看起来最终会出现在 express5 中......）
• 减少依赖。 在构建无状态 API 或微服务时能够使用原始节点 http(s) 或更小的东西（主要羽毛用例）
• 成为未来的证明👍
• 变得更加模块化，以便您可以交换您的路由器、模板引擎等。Feathers 确实只是核心技术之上的架构模式 + 实用程序库。

在我看来，除了 Express 之外，第一个支持的“引擎”将是 Koa。 它在设计上与 Express 最相似，并为未来的 ES6/ES7 语言功能提供了很好的支持。 这似乎也是我们最需要的。 就我个人而言，我宁愿支持原始节点库，但这可能需要做很多工作。

需要发生什么

• [ ] 识别常见的顶级 Feathers API。 我认为在我们至少尝试下面的另一个引擎之前，我们无法完全识别这一点。 但是我会❤️因为它很简单：

  const feathers = require('feathers');
  const app = feathers();
  
  // use by string name
  app.engine('express');
  
  // or pass the engine with string
  const koa = require('koa');
  app.engine('koa', koa);
  
  // or simply pass the engine. I like this best
  const koa = require('koa');
  app.engine(koa);
  

  这在概念上类似于@jeffijoe的建议，但是，我希望人们感觉他们正在直接与 Feathers 应用程序交互。 我认为这将使 API 更简洁。 然而，话虽如此，现在说还为时过早，因为我们可能不得不填充大量的方法。 在我们确定顶级 API 之前，需要进一步调查。

• [ ] 确保使用的所有 express 方法都是 polyfill、别名，或者我们删除对它们的依赖。 可能还有更多，但我能想到的有：
  
  
  
  • app.get
  
  
  • app.set
  
  
  • app.render
  
  
  • app.send
  
  
  • app.json
  
  
  • req.accepts
  
  
  • req.xhr
  
  
• [] 使身份验证引擎/传输不可知 (https://github.com/feathersjs/feathers-authentication/pull/336)
• [ ] 别名/更改我们注册 REST 路由的方式。
• [ ] 别名/改变我们如何设置套接字

可能还有更多的东西。 @daffl会有更好的主意，特别是在套接字/休息设置方面。

其他注意事项

• 我们会支持 Express 的所有 HTTP 动词方法吗？ 有很多。 这不是意味着要实施很多 Express 吗？
• 我们目前依赖哪些 Express 特定的东西？
• 您希望将app对象上的哪些辅助方法保留为核心 Feathers API 的一部分。
• Express 5 的提案是什么样的？ 好久没看了。 最好与@dougwilson 联系，看看我们是否可以伸出援手（如果有意义的话，那个厨房里可能已经有足够的厨师了）。
• 是否有像@dougwilson正在开发的模块或spiritjs 、 http-framework等模块，它们可以为我们提供模块化，而无需在核心节点功能之上重写这些抽象。

// or simply pass the engine. I like this best
const koa = require('koa');
app.engine(koa);

同意！ 这样，人们可以学习一次 Feathers 并部署在任何有适配器的服务器上。 好点子！

挑战在于转换依赖于特定连接的东西（如标头）的库。

关于人气竞赛，我想使用 Koa 的主要原因不是因为它很受欢迎（不如 express 那么多），而是因为它在处理中间件错误方面更稳定。

请让我们将 Feathers 迁移到更适合瘦 API 网关（经典 Web 服务器）和可独立部署且与协议无关的愚蠢/简单 Web 服务的架构，只收听感兴趣的消息（即最佳实践微服务）图案）。 然后我们就可以开始与 Seneca 和其他流行的 Node.js 微服务框架顺利集成。

是的，FeathersJS 应该与 Express、Koa、Hapi 等无关......
我也很想在 Nginx 上使用 HTTP2/Push 看到它 :)

快乐的时光！

你们看过这个https://github.com/fastify/fastify 吗？

我很想将它与 FeathersJS 一起使用，这个问题的状态是什么？

@andreafalzetti仍在继续前进。 你可以在这里看到一些进展： https ://github.com/feathersjs/feathers-express/issues/3

是的，将羽毛与 fastify 结合起来会非常甜蜜！ 我们开始做吧 ：）

基本的集成应该是相当简单的，但是，它是身份验证（特别是护照和 oAuth）让事情变得棘手。

我们的计划是消除对 Express 的硬依赖，并在 v3 之后调查哪些集成是有意义的。 上周我在 Fastify 上看到了一个演讲，虽然很有趣，但 Feathers 使用 Nodes HTTP（和 HTTP2！）与 Fastify 用作主要集成的路由器可能更有意义。

仅供参考，我开始在 feathers -rest-koa中进行 feathers-koa REST 集成工作

我认为将 REST 客户端提取到单独的模块/包和 repo 中是有意义的；）

客户已经在https://github.com/feathersjs/feathers-rest-client也相关： https ://github.com/feathersjs/feathers-express/issues/3 @christopherjbaker

作为 Feathers 的新手：到 2018 年 Feathers 完全独立于 Express 了吗？

编辑：或者换句话说：支持哪些其他框架。 是否完全支持 KOA？

谢谢！ 喜欢这个框架，感谢您的辛勤工作！

问@daffl ，他一直在努力……但不确定目前的情况。

Feathers 是独立于框架的（例如，您只能将其与@feathersjs/socketio 一起使用或作为独立客户端与其他服务通信），但它仅具有 Express 的 HTTP API 绑定（在@feathersjs/express中）。

由于 Feathers 的重点是抽象协议特定的东西，它最终使用的 HTTP 框架应该没有那么重要，从 Express 中抽象出身份验证之类的东西是一项相当大的任务（所有 Passport 都是为 Express 构建的，甚至当前的 Koa 集成只是通过修改其请求对象使其看起来像 Express 来绕过这个事实）。 对我来说，新框架绑定的最高优先级是纯 Node HTTP，它具有新的服务查找机制，将产生与 Fastify 相似的性能，并使 websocket 连接更快。

由于关闭后最近没有任何活动，因此此问题已自动锁定。 请打开一个新问题，其中包含指向此问题的链接以获取相关错误。