Feathers: Haga que el marco del servidor Feathers sea independiente para trabajar con Express, Koa y Hapi

Creo que la mayor barrera para esto será la autenticación, específicamente cómo obtenemos acceso al objeto de solicitud y respuesta y cómo funciona el middleware de pasaporte con Koa, etc.

De un vistazo rápido, no se ve tan mal con Koa. Solo necesitaríamos usar https://github.com/rkusa/koa-passport-example y ctx en lugar de req y res . Con Hapi no estoy tan seguro, pero no estoy convencido de que sea de gran valor apoyar a Hapi, en realidad no proporciona nada diferente a Express. Al menos con Koa tienes soporte de generador.

En mi humilde opinión, si buscamos ser más flexibles y no estar atados a un marco, probablemente sea mejor usar módulos independientes para el enrutamiento, la negociación de contenido, etc.

Para soporte de socket con Koa usamos esto como inspiración: https://github.com/koajs/koa.io.

En mi humilde opinión, si buscamos ser más flexibles y no estar atados a un marco, probablemente sea mejor usar módulos independientes para el enrutamiento, la negociación de contenido, etc.

http-framework ! :guiño:

@ahdinosaur ya parece más bien el camino correcto en mi humilde opinión.

Creo que deberíamos hacer de Feathers una biblioteca en lugar de un marco, eso también lo haría más independiente en el transporte.

Ejemplos:

Código común

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

Específico del marco

Koa

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

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

Rápido

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

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

Básicamente, los adaptadores crearán el middleware para su marco particular.

Nota: https://github.com/spirit-js/spirit

@daffl Acabo de comprobar el espíritu y se ve muy bien. Sería increíble desacoplar las plumas del expreso. Con el surgimiento de tantas implementaciones nuevas diferentes de express, las plumas serían más sólidas en el futuro. ¿Alguna decisión al respecto?

Este PR de autenticación https://github.com/feathersjs/feathers-authentication/pull/336 debería ser la única pieza importante que necesitamos para poder admitir diferentes marcos debajo.

Estuve pensando mucho más en esto durante los últimos días y ahora que nos estamos acercando a cerrar Auk, este será el objetivo principal para el lanzamiento de Buzzard. Tan bueno como es ser modular mirando los números de uso, Express no va a ninguna parte. Tiene 70 millones de descargas este último año , Koa está a la altura con 1,4 millones y Hapi con ~2,4 millones .

_Creo que estos números pueden inflarse artificialmente por los sistemas de compilación, la frecuencia de implementación, el tamaño de las implementaciones, etc., pero esto da una idea general de cuán populares son las cosas._

Siendo completamente honesto, mirando los números, realmente no hay muchos incentivos para apoyar nada más que expresar. Las principales razones que veo serían:

• soporte de http2 (que parece que llegará en express5 eventualmente....)
• reducción de dependencias. Ser capaz de usar http(s) de nodo sin procesar o algo más mínimo cuando está creando una API sin estado o un microservicio (caso de uso de plumas primarias)
• siendo prueba de futuro 👍
• cada vez más modular, para que pueda intercambiar su enrutador, motores de plantillas, etc. Feathers realmente es solo un patrón arquitectónico + utilidad lib además de la tecnología central.

En mi opinión, el primer "motor" compatible con otro que no sea Express sería Koa. Es el más similar en diseño a Express y proporciona un buen soporte para futuras funciones de lenguaje ES6/ES7. También parece ser nuestro más solicitado. Personalmente, preferiría tener soporte para bibliotecas de nodos sin procesar, pero eso podría ser mucho trabajo.

que tiene que pasar

• [ ] Identifique la API Feathers de nivel superior común. No creo que podamos identificar esto completamente hasta que probemos al menos otro motor debajo. Sin embargo, quisiera ❤️ que fuera tan fácil como:

  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);
  

  Esto es conceptualmente similar a lo que sugirió @jeffijoe , sin embargo, preferiría que las personas sintieran que están interactuando directamente con una aplicación de Feathers. Creo que será una API más limpia. Sin embargo, dicho esto, es un poco pronto para decirlo, ya que es posible que tengamos que ajustar una tonelada de métodos. Se requerirá más investigación antes de que podamos determinar la API de nivel superior.

• [ ] Asegúrese de que todos los métodos expresos que se utilizan estén polillenados, con alias o eliminemos la dependencia de ellos. Puede haber más, pero los que puedo pensar en la parte superior de mi cabeza son:
  
  
  
  • app.get
  
  
  • app.set
  
  
  • app.render
  
  
  • app.send
  
  
  • app.json
  
  
  • req.accepts
  
  
  • req.xhr
  
  
• [ ] Hacer que el motor de autenticación/transporte sea independiente (https://github.com/feathersjs/feathers-authentication/pull/336)
• [ ] Alias/alterar cómo registramos las rutas REST.
• [ ] Alias/alterar cómo configuramos los sockets

Puede haber más cosas. @daffl tendría una mejor idea, específicamente sobre la configuración de socket/descanso.

Otras Consideraciones

• ¿Vamos a admitir todos los métodos de verbos HTTP de Express? Hay muchos ¿No significaría eso implementar mucho Express?
• ¿En qué cosas específicas de Express confiamos actualmente?
• ¿Qué métodos auxiliares en el objeto app desea mantener como parte de la API principal de Feathers?
• ¿Qué aspecto tiene Express 5 para la propuesta? Ha pasado un tiempo desde que lo miré. Sería bueno conectarse con @dougwilson y ver si podemos echar una mano (si tiene sentido, es posible que ya haya suficientes cocineros en esa cocina).
• ¿Hay módulos como en los que estaba trabajando @dougwilson o spiritjs , http-framework , etc. que nos darían la modularidad sin tener que reescribir esas abstracciones sobre la funcionalidad del nodo central?

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

¡Acordado! De esta manera, las personas pueden aprender Feathers una vez e implementarlo en cualquier servidor que tenga un adaptador. ¡Gran idea!

El desafío radica en convertir bibliotecas que se basan en elementos específicos de la conexión, como los encabezados.

Acerca del concurso de popularidad, mi razón principal para querer usar Koa no es porque sea popular (no tanto como express), sino porque es más estable en términos de manejo de errores de middleware.

Movamos Feathers a una arquitectura más adecuada para una puerta de enlace API delgada (servidor web clásico) y servicios web estúpidos/simples que se pueden implementar de forma independiente y son independientes del protocolo, solo escuchan mensajes de interés (es decir, Micro Servicio de mejores prácticas patrón). Luego, podemos comenzar a integrarnos sin problemas con Seneca y otros marcos populares de microservicios de Node.js.

Y sí, FeathersJS debería ser independiente de Express, Koa, Hapi, lo que sea...
Me encantaría verlo en Nginx con HTTP2/Push también :)

¡Días felices!

¿Habéis visto esto https://github.com/fastify/fastify?

Me encantaría usarlo con FeathersJS, ¿cuál es el estado de este problema?

@andreafalzetti sigue avanzando. Puede ver algunos avances aquí: https://github.com/feathersjs/feathers-express/issues/3

Sí, ¡sería genial integrar plumas con Fastify! Vamos a hacerlo :)

La integración básica debería ser bastante sencilla, sin embargo, es la autenticación (específicamente pasaporte y oAuth) donde las cosas se ponen difíciles.

Nuestro plan era eliminar la dependencia estricta de Express y, después de v3, investigar qué integraciones tienen sentido. Vi una charla sobre Fastify la semana pasada y, si bien fue interesante, podría tener aún más sentido que Feathers simplemente use Nodes HTTP (¡y HTTP2!) con el enrutador que Fastify está usando como integración principal.

Para su información, comencé a trabajar en la integración de plumas-koa REST en plumas-rest-koa

Creo que tendría sentido extraer el cliente REST en un módulo/paquete separado y un repositorio;)

Los clientes ya están en https://github.com/feathersjs/feathers-rest-client también relacionado: https://github.com/feathersjs/feathers-express/issues/3 por @christopherjbaker

Como novato en Feathers: ¿Para 2018, Feathers es completamente independiente de Express?

EDITAR: O en otras palabras: qué otros marcos son compatibles. ¿KOA es totalmente compatible?

¡Gracias! Me encanta el marco y gracias por el arduo trabajo!

Pregúntale a @daffl , ha estado trabajando en ello... Sin embargo, no estoy seguro del estado actual de las cosas.

Feathers es independiente del marco (por ejemplo, solo puede usarlo con @feathersjs/socketio o como un cliente independiente para hablar con otros servicios), pero solo tiene enlaces HTTP API para Express (en @feathersjs/express ).

Dado que el objetivo de Feathers es abstraer las cosas específicas del protocolo, el marco HTTP que está utilizando en última instancia no debería importar tanto y abstraer cosas como la autenticación lejos de Express es una tarea bastante grande (todo Passport está diseñado para Express e incluso las integraciones actuales de Koa simplemente eluden ese hecho jugando con su objeto de solicitud para que parezca Express). Para mí, la prioridad más alta para los nuevos enlaces de marco sería Node HTTP simple, que con un nuevo mecanismo de búsqueda de servicios produciría un rendimiento similar al de Fastify y haría que las conexiones websocket fueran aún más rápidas.

Este problema se ha bloqueado automáticamente ya que no ha habido ninguna actividad reciente después de que se cerró. Abra un nuevo problema con un enlace a este problema para ver los errores relacionados.