Feathers: Jadikan kerangka server Feathers independen untuk bekerja dengan Express, Koa, dan Hapi

Dibuat pada 12 Mar 2016 · 22Komentar · Sumber: feathersjs/feathers

Sekarang Feathers sudah bekerja perpustakaan independen pada klien (lihat https://github.com/feathersjs/feathers/pull/193), kami tidak benar-benar membutuhkan Express sebagai ketergantungan keras untuk server lagi. Sebagai gantinya, kita dapat membuat modul terpisah untuk Express, Koa, dan kemungkinan Hapi yang dapat dikonfigurasi seperti plugin lainnya:

cepat

Satu-satunya hal untuk mengubah pemutakhiran dari aplikasi Feathers 2 adalah menjadi app.configure(express()) :

const feathers = require('feathers');
const express = require('feathers-express');

const app = feathers()
  // Make this app Express compatible
  .configure(express())
  // Configure REST API that uses Express
  .configure(express.rest());

// Use any Express middleware
app.use(bodyParser.json());
// Use Feathers services normally
app.use('/todos', {
  get(id) {
    return Promise.resolve({ id, description: `You have to do ${id}!` });
  }
});

Koa

Dukungan Koa muncul beberapa kali (lihat #83 dan #58). Ini sekarang dapat dilakukan dengan sangat mirip:

const feathers = require('feathers');
const koa = require('feathers-koa');

const app = feathers()
  // Make this app Koa compatible
  .configure(koa())
  // Configure Koa REST handler
  .configure(koa.rest());

// Use normal Koa middleware
app.use(function *(){
  this.body = 'Hello World';
});

// Use a Feathers service through app.service
app.service('/todos', {
  get(id) {
    return Promise.resolve({ id, description: `You have to do ${id}!` });
  }
});

Breaking Change Feature Proposal

Sumber

daffl

👍25 🎉8

Komentar yang paling membantu

Saya pikir kita harus menjadikan Feathers sebagai perpustakaan alih-alih kerangka kerja - yang akan membuatnya lebih mandiri dalam transportasi juga.

Contoh:

Kode umum

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

Kerangka khusus

Koa

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

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

cepat

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

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

Pada dasarnya, adaptor akan membuat middleware untuk kerangka kerja khusus mereka.

jeffijoe pada 20 Mei 2016

👍14

Semua 22 komentar

Hambatan terbesar untuk ini menurut saya adalah otentikasi, khususnya bagaimana kami mendapatkan akses ke objek permintaan dan respons dan bagaimana middleware paspor bekerja dengan Koa, dll.

Sepintas tidak terlihat terlalu buruk dengan Koa. Kami hanya perlu menggunakan https://github.com/rkusa/koa-passport-example dan ctx alih-alih req dan res . Dengan Hapi saya tidak begitu yakin tetapi saya tidak yakin ada banyak nilai dalam mendukung Hapi, itu tidak benar-benar memberikan sesuatu yang berbeda dari Express. Setidaknya dengan Koa Anda memiliki dukungan generator.

IMHO, jika kita ingin lebih fleksibel dan tidak terikat pada kerangka kerja, kita mungkin lebih baik menggunakan modul mandiri untuk perutean, negosiasi konten, dll.

ekryski pada 12 Mar 2016

Untuk dukungan soket dengan Koa, kami menggunakan ini untuk inspirasi: https://github.com/koajs/koa.io.

ekryski pada 12 Mar 2016

IMHO, jika kita ingin lebih fleksibel dan tidak terikat pada kerangka kerja, kita mungkin lebih baik menggunakan modul mandiri untuk perutean, negosiasi konten, dll.

http-framework ! :mengedip:

ahdinosaur pada 16 Mar 2016

@ahdinosaur ya itu sepertinya cara yang lebih tepat untuk pergi IMHO.

ekryski pada 16 Mar 2016

Saya pikir kita harus menjadikan Feathers sebagai perpustakaan alih-alih kerangka kerja - yang akan membuatnya lebih mandiri dalam transportasi juga.

Contoh:

Kode umum

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

Kerangka khusus

Koa

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

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

cepat

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

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

Pada dasarnya, adaptor akan membuat middleware untuk kerangka kerja khusus mereka.

jeffijoe pada 20 Mei 2016

👍14

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

daffl pada 12 Agu 2016

👍4

@daffl Saya baru saja memeriksa semangat dan terlihat sangat rapi. Akan luar biasa untuk memisahkan bulu dari ekspres. Dengan munculnya begitu banyak implementasi baru yang berbeda dari express akan membuat bulu lebih kuat di masa depan. Ada keputusan tentang ini?

rickmed pada 17 Agu 2016

PR Otentikasi ini https://github.com/feathersjs/feathers-authentication/pull/336 harus menjadi satu-satunya bagian utama yang kami butuhkan untuk dapat mendukung berbagai kerangka kerja di bawahnya.

ekryski pada 31 Okt 2016

Saya telah memberikan ini lebih banyak pemikiran selama beberapa hari terakhir dan sekarang kita semakin dekat dengan penutupan Auk ini akan menjadi tujuan utama untuk rilis Buzzard. Sebagus itu menjadi modular melihat nomor penggunaan Express tidak ke mana-mana. Ini memiliki 70 juta unduhan tahun lalu , Koa ada di atas sana dengan 1,4 juta dan Hapi dengan ~2,4 juta .

_Saya pikir angka-angka ini dapat ditingkatkan secara artifisial oleh sistem build, frekuensi penerapan, ukuran penerapan, dll. tetapi ini memberikan gambaran umum tentang seberapa populer hal-hal tersebut._

Menjadi benar-benar jujur, melihat angka-angka sebenarnya tidak ada banyak insentif untuk mendukung apa pun selain mengungkapkan. Alasan utama yang saya lihat adalah:

dukungan http2 (yang tampaknya akan datang di express5 pada akhirnya ....)
mengurangi ketergantungan. Mampu menggunakan simpul mentah http(s) atau sesuatu yang lebih minimal saat Anda membangun API atau layanan mikro stateless (kasus penggunaan bulu utama)
menjadi bukti masa depan 👍
menjadi lebih modular, sehingga Anda dapat menukar router, mesin templat, dll. Bulu sebenarnya hanyalah pola arsitektur + lib utilitas di atas teknologi inti.

Dalam pikiran saya, "mesin" pertama yang mendukung selain Express adalah Koa. Ini adalah desain yang paling mirip dengan Express dan memberikan dukungan yang bagus untuk fungsi bahasa ES6/ES7 di masa mendatang. Itu juga tampaknya menjadi yang paling kami minta. Secara pribadi saya lebih suka memiliki dukungan untuk lib simpul mentah tetapi itu mungkin banyak pekerjaan.

Apa yang perlu terjadi?

[ ] Identifikasi API Bulu tingkat atas yang umum. Saya tidak berpikir kami dapat mengidentifikasi ini sepenuhnya sampai kami mencoba setidaknya satu mesin lain di bawahnya. Namun saya akan ❤️ agar semudah:
```
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);
```
Ini secara konseptual mirip dengan apa yang disarankan @jeffijoe , saya lebih suka orang merasa bahwa mereka berinteraksi dengan aplikasi Feathers secara langsung. Saya pikir itu akan membuat API yang lebih bersih. Namun, dikatakan masih terlalu dini untuk mengatakannya karena kita mungkin harus menggunakan banyak metode. Penyelidikan lebih lanjut akan diperlukan sebelum kami dapat menentukan API tingkat atas.
[ ] Pastikan semua metode ekspres yang digunakan adalah polifill, alias atau kita hilangkan ketergantungannya. Mungkin ada lebih banyak tetapi yang dapat saya pikirkan dari atas kepala saya adalah:
- app.get
- app.set
- app.render
- app.send
- app.json
- req.accepts
- req.xhr
[ ] Jadikan mesin auth/transport agnostik (https://github.com/feathersjs/feathers-authentication/pull/336)
[ ] Alias /mengubah cara kami mendaftarkan rute REST.
[ ] Alias /mengubah cara kami mengatur soket

Mungkin ada lebih banyak hal. @daffl akan memiliki ide yang lebih baik, khususnya di sekitar pengaturan soket/istirahat.

Pertimbangan lainnya

Apakah kita akan mendukung semua metode kata kerja HTTP Express? Ada banyak . Bukankah itu berarti menerapkan banyak Express?
Hal spesifik Express apa yang saat ini kami andalkan?
Metode pembantu apa pada objek app yang ingin Anda pertahankan sebagai bagian dari API Feathers inti.
Seperti apa Express 5 untuk proposal? Sudah lama sejak saya melihatnya. Akan lebih baik untuk terhubung dengan @dougwilson dan melihat apakah kami dapat membantu (jika masuk akal, mungkin sudah ada cukup banyak juru masak di dapur itu).
Apakah ada modul seperti yang sedang dikerjakan @dougwilson atau spiritjs , http-framework , dll. yang akan memberi kita modularitas tanpa harus menulis ulang abstraksi tersebut di atas fungsionalitas simpul inti.

ekryski pada 31 Okt 2016

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

Sepakat! Dengan cara ini, orang dapat mempelajari Feathers sekali dan menerapkannya di server mana pun yang memiliki adaptor. Ide yang hebat!

Download pada 1 Nov 2016

Tantangannya terletak pada mengonversi perpustakaan yang mengandalkan hal-hal khusus koneksi seperti header.

Tentang kontes popularitas, alasan utama saya ingin menggunakan Koa bukan karena populer (tidak sebanyak express), tetapi karena lebih stabil dalam menangani kesalahan middleware.

jeffijoe pada 1 Nov 2016

👍4

Silakan pindahkan Feathers ke arsitektur yang lebih cocok untuk gateway API tipis (server web klasik) dan layanan web bodoh/sederhana yang dapat digunakan secara mandiri dan tidak bergantung pada protokol, hanya mendengarkan pesan yang menarik (mis. praktik terbaik Layanan Mikro pola). Kemudian kita dapat mulai berintegrasi dengan lancar dengan Seneca dan kerangka kerja Layanan Mikro Node.js populer lainnya.

Dan ya, FeathersJS harus agnostik terhadap Express, Koa, Hapi, apa pun ...
Saya ingin melihatnya di Nginx dengan HTTP2/Push juga :)

Hari bahagia!

kristianmandrup pada 8 Mar 2017

Pernahkah kalian melihat ini https://github.com/fastify/fastify?

Saya ingin menggunakannya dengan FeathersJS, apa status masalah ini?

andreafalzetti pada 5 Okt 2017

👍2

@andreafalzetti masih bergerak maju. Anda dapat melihat beberapa kemajuan yang terjadi di sini: https://github.com/feathersjs/feathers-express/issues/3

marshallswain pada 9 Okt 2017

👍1

Ya, akan sangat manis untuk mengintegrasikan bulu dengan fastify! Ayo lakukan :)

kristianmandrup pada 12 Okt 2017

Integrasi dasar harus cukup mudah, namun otentikasi (khususnya paspor dan oAuth) di mana segala sesuatunya menjadi berbulu.

Rencana kami adalah menghapus ketergantungan keras pada Express dan setelah v3 menyelidiki integrasi apa yang masuk akal. Saya melihat pembicaraan di Fastify minggu lalu dan meskipun menarik, mungkin lebih masuk akal jika Feathers hanya menggunakan Nodes HTTP (dan HTTP2!) dengan router yang digunakan Fastify sebagai integrasi utama.

daffl pada 12 Okt 2017

👍1

FYI, saya mulai mengerjakan integrasi feathers-koa REST di feathers-rest-koa

Saya pikir masuk akal untuk mengekstrak klien REST ke dalam modul/paket dan repo terpisah;)

kristianmandrup pada 12 Okt 2017

Klien sudah ada di https://github.com/feathersjs/feathers-rest-client juga terkait: https://github.com/feathersjs/feathers-express/issues/3 oleh @christopherjbaker

daffl pada 12 Okt 2017

Sebagai pemula di Feathers: Pada 2018 apakah Feathers sepenuhnya independen dari Express?

EDIT: Atau dengan kata lain: Kerangka kerja lain mana yang didukung. Apakah KOA didukung penuh?

Terima kasih! Sukai kerangka kerjanya dan terima kasih atas kerja kerasnya!

bitflower pada 24 Jan 2018

Tanyakan @daffl , dia sedang mengerjakannya... Tidak yakin tentang keadaan saat ini.

kristianmandrup pada 24 Jan 2018

👍1

Feathers adalah kerangka kerja independen (seperti dalam Anda dapat misalnya hanya menggunakannya dengan @feathersjs/socketio atau sebagai klien mandiri untuk berbicara dengan layanan lain) tetapi hanya memiliki binding HTTP API untuk Express (dalam @feathersjs/express ).

Karena inti dari Feathers adalah mengabstraksi hal-hal khusus protokol, kerangka kerja HTTP yang digunakannya pada akhirnya seharusnya tidak terlalu penting dan mengabstraksi hal-hal seperti otentikasi dari Express adalah tugas yang cukup besar (semua Paspor dibuat untuk Express dan bahkan integrasi Koa saat ini hanya meretas fakta itu dengan mengacaukan objek permintaannya agar terlihat seperti Express). Prioritas tertinggi untuk pengikatan kerangka kerja baru bagi saya adalah HTTP Node biasa yang dengan mekanisme pencarian layanan baru akan menghasilkan kinerja yang serupa dengan Fastify dan membuat koneksi websocket lebih cepat.

daffl pada 24 Jan 2018

👍3

Masalah ini telah dikunci secara otomatis karena tidak ada aktivitas terbaru setelah ditutup. Silakan buka masalah baru dengan tautan ke masalah ini untuk bug terkait.