Repository navigation
Adapter for express js middleware #47
Description
Being able to reuse existing express middleware would be really nice in hyper. As it currently is, nodejs apps using express that are transitioning to purescript wouldn't be able to switch to hyper immediately because all of their infrastructure would be bound to the express middleware. They would be forced to either use the express wrapper (not ideal) or leave it as is (even worse).
I think hyper middleware should be completely compatible with express middleware as far as I can tell. What needs to be done to get this adapter going?
Activity
owickstrom commentedon Sep 6, 2017
This is indeed an interesting proposal, and it has been on my TODO list before. 🙂 Not sure why there's no issue or note of it anywhere.
As long as they're using the Hyper.Node.Server, then yes, everything could be compatible. Then it is up to the one doing the FFI binding to provide a proper type signature, and perhaps to provide a value in the
componentsof the Conn. Such a value can be parameterized to safely track state, if needed.The tricky part, I guess, is that many Express middleware might perform a side effect, or not, and then just hand over to the next, which also might perform side effects. Indeed, this is why I started with Hyper in the first place. 😄 But I think Express middleware should be "lifted" to Hyper on an individual basis, not with a general
liftMiddlewarethat "works" on any Express middleware, as their type signatures and effects probably will differ a lot.One other thing, which I wanted to write about but I haven't had time, is how error handling differs with Hyper from Express (as we're tracking effects). In Express, errors are passed in continuations to signal that the response hasn't been sent and that it's up to someone else to do it. In Hyper, you need to "wrap" fallback middleware with other middleware that might fail. For example, the fileServer middleware takes an
on404middleware as a fallback. This affects how Express middleware should be integrated as well. Maybe a generic function for doing FFI, that takes an Express middleware and returns a Hyper middleware with a similar type tofileServer, could work.To sum up; I think this is valuable step for Hyper to take, and that it could, as you say, enable more projects to gradually migrate from Express. That is probably the selling point. I think Haskellers are unlikely to jump on the NodeJS runtime just to track side effects in middleware with Hyper, but battle-scarred NodeJS developers might long for some type safety in their backend projects.
Risto-Stevcev commentedon Sep 6, 2017
Yeah that's true. For the express middleware I've used before, it modifies the request or response object and add a new property to it, and it also performs a side effect like reading/writing to a database (like for a store for passportjs)
I might try to write some kind of adapter, I'm transitioning an old nodejs express app and I really want to use hyper for it instead of express. But I'm a ways away from getting to that part of the code