Hapi and Koa integration

[thomrick]

Express is a very great Node server library, but some project also use Hapi or Koa.
Does it a good idea to integrate them into Nest as adapters and let people choose the one they want / need ?

[zachgrayio]

I'm not part of the Nest team in any way right now, but I've got some opinions I'd like to add to this discussion :)

IMO, Hapi is all about configuration over code, and they have a nice API for this. Express, while being faster, was always nastier to configure (imo, just to reiterate).

What Nest excels at is essentially allowing you to combine your config and your code seamlessly by making use of TypeScript decorators, instead of defining config JSON and wrapping in a controller reference like Hapi does, or doing it all in express code. It uses express under the hood, sure, but this is really just an implementation detail. In a perfect world, you'd never write any pure Express code yourself, or any Hapi / Koa code, if they were supported underlying frameworks.

Using Hapi, etc for the underlying engine would also probably be less optimal, primarily because it's slower than Express, and also it'd probably be a much harder task to generate the Hapi config than it is to hook into express and create routes and so on (ironically, in this case, express's much cited weakness becomes it's strength). I'm just guessing on this last point, as I didn't write any of this code.

Given the above, I'm curious, what would the motivation be for supporting multiple frameworks beyond Express?

[ktutnik]

@thomrick from the source code i see that express is tightly coupled with the implementation no abstraction done, would required massive modification to support hapi/koa (next version maybe?)

@zachgrayio agree with @thomrick supporting other framework would increase reusability of already created middlewares etc.

[kamilmysliwiec]

Hi @thomrick,
I totally agree with @zachgrayio. The support for the other popular libraries is not needed. Nest is here to provide an architecture, especially to build scalable and loosely coupled systems. What is under the hood is just an implementation detail. I chose express, because - it is fast, popular and there is a lot of ready to use 3rd-party libraries.

[thomrick]

Hey guys,

Totally agree with you. It was just a suggestion.

[amitport]

@kamilmysliwiec
"Nest is here to provide an architecture, especially to build scalable and loosely coupled systems"

It is coupled with express though.
Those of us who have a set of complext hapi/koa middlewares cannot just use your "provided architecture". (which looks great btw).

[jhanschoo]

@kamilmysliwiec I'd like to fork and branch and look into seeing if it's possible to loosen the coupling between Nest and Express, and see what the cost of supporting Koa and Hapi would be.

Ideally, there should be a way for teams to smoothly transition from an app built on Koa/Hapi/ to a DI-enabled NestJS framework, slowly chipping away at the old architecture.

[wbhob]

Again, @amitport though it is coupled with express, it doesn't matter. When you elect to use Nest, you must elect to use express, because it's the foundation of the house that Nest is built on; it handles HTTP, while Nest handles syntax sugar and developer experience.

I realize that it is probably a pain to transition all your routes, but if you want to use Nest, it's one of the steps to getting there.

In terms of loose coupling in the snippet you provided, the loose coupling is between the frontend and backend, and between individual controllers, not between Nest and the underlying framework.

@jhanschoo I imagine it would be fairly difficult to decouple Express and Nest, and to integrate Hapi or Koa, because all of those APIs are completely different, and maintaining three different forks of code that essentially do almost the same thing is needlessly laborious.

[jhanschoo]

FeathersJS is trying something similar. (feathersjs/feathers#258)

I'll do some research and give it a try; I'd like to see if it can't be refactored into an API+officially supported Express plugin. The other interfaces can be community-maintained.

[amitport]

@wbhob, I do think it's a very important for wider adoption (it could facilitate migration and protect from vendor lock-in), but I understand it may not be cost/time-effective. @jhanschoo I appreciate any effort,

Thank you

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.