Koa Feathers transport

[daffl]

From @christopherjbaker on September 30, 2017 22:23

I'm not sure this is the right place to add this issue, but I'm not sure where would be better.

With prompting from @marshallswain, I've been working on a feathers-koa (very early, mostly proof-of-concept), to complement this package. I have been running into some issues, however, primarily as much of the feathers code is expecting things to follow express conventions, which koajs (obviously) does not. Some of these are more easily surmountable (though hacky) than others. I am hoping we can come up with a solution that works well with both.

First, the issues:

All of the places that feathers passes a middleware function to app.use, that middleware takes the form function(req, res, next) (as express does). Koa middleware takes the form function({ request, response, req, res }, next) (where req and res are the node-native objects, and request and response are helper objects with QOL methods which access req/res). This was surmounted by modifying the middleware methods before passing them on. While this works, it feels very hacky.

function expressifyMiddleware(args) {
	for (let index in args) {
		let original = args[index];
		if (typeof original === 'function') {
			args[index] = function({ req, res }, next) {
				original.call(this, req, res, next);
			};
		}
	}
}

feathers-rest makes use of an app.route method, which returns an object containing get, post, etc. I added a router to koa (as it does not contain one in the core) and built a method which returns a similar object (each of which had to be passed to expressifyMiddleware).

Some are proving to be more difficult to overcome, however. The req and res objects provided by express are the native ones, with some extras added. My first thought was to modify feathers-rest to not use those helpers and thus be compatible with the native objects. This worked for res.status(x) (res.statusCode = x) and res.format() (removed, as it isn't really accomplishing anything). req.params, req.query, req.body, and req.json are not native, however. They could be emulated by modifying the req/res objects before passing them in, just like express does.

I was wondering if you had a preferred approach to this. While I could do a wrapper like express does, and apply expressifyMiddleware all over the place, that is not very forward compatible (express could change, request 5 could have a different api, other frameworks would expect a third set of requirements, etc). My thoughts here would be for feathers modules to only use native methods, and any needed helpers to be applied to those native objects by feathers, and to ignore (or preferably remove entirely) those provided by express/koa/etc. I think some of these would be provided by feathersjs (res.status() (possibly just use res.statusCode instead), req.params, req.query, 'req.body), and others by feathers-express, feathers-koa, and feathers- as needed (res.json()).

Copied from original issue: feathersjs-ecosystem/express#3

[daffl]

Thank you for starting this @christopherjbaker! Some notes on this from me:

• Each framework binding should bring it's own REST provider. feathers-rest should really live in this repository (something like feathers-express/rest or require('feathers-express').rest)
• feathers-authentication v2 somehow needs a more abstracted way to authenticate a request. Then the framework binding should detect what authentication routes it has to register.

I don't think we should try and make Express middleware work. I did see koa-connect which has a big warning to only use it when absolutely needed.

[daffl]

From @christopherjbaker on October 2, 2017 17:55

Having each provide their own feathers-rest would certainly alleviate much of the hackery needed. feathers-errors also has some middleware specific code, however (error-handler and not-found-handler). That whole thing definitely shouldn't be moved over.

[daffl]

From @kristianmandrup on October 14, 2017 21:16

Hi @christopherjbaker,

Very happy to see this issue!
I've started a feathers-rest-koa like you suggest, which is using feathers-koa to "koaify" a feathers app and then adding/configuring routes for koa (and express). Very easy to customise/extend for any framework/web server.

Let's collaborate! I've come pretty far already on the REST side. Cheers!

[daffl]

From @kristianmandrup on October 15, 2017 18:54

@christopherjbaker I've come really far with a much more extensible approach (I think). Would love some feedback and assistance to finish it off ;)

[kristianmandrup]

Sounds great @daffl :) I'd love to see this working out.

I'm currently busy building a React app and not using FeathersJS for the time being. Would love to see it targeted more towards a micro services approach such as one service per Kubernetes pod or one endpoint per AWS lamda function or similar.
Ideally using something like SenchaJS micro services with a Message Service bus as transport layer for pub/sub messages between services.

Deploying a pure old-school REST only server with all endpoints in a huge monolith seems like an ancient approach by now IMO. What is the latest FeathersJS shaping up to be?

Cheers!

[daffl]

This issue is more intended for creating a Feathers transport adapter for Koa. There is a more recent microservice discussion in #939.