Consider moving from express to hapi

[mattapperson]

I will start by saying I don't know that I truly expect this to be accepted (though I truly hope it is).
I also understand that what I am suggesting is a little "boil the ocean", but I beg that you hear me out.

My main reason for wanting to see Keystone move to Hapi is the ability to break things up.
With Express, you have middleware functions. Middleware functions are kind of like filters that you stack up and all requests run through them before hitting your handler.
hapi has the request lifecycle and offers extension points, which are comparable to middleware functions but exist a several defined points in the request lifecycle.
One of the reasons that Walmart built hapi and stopped using Express was a frustration with how difficult it was to split a Express app into separate parts, and have different team members work safely on their chunk. For this reason they created the plugin system in hapi. I would argue that this is a critical aspect for any team of sufficient size. I would further argue that what larger "team" can their be then such a thriving community as what Keystone has.

This argument though becomes even more important when you consider the desire to introduce the idea of plugins to Keystone. Although you can technically do this with express for sure, the Hapi way is far more robust. In Hapi a plugin is like a sub-application, you can do everything you can in a hapi app, add routes, extensions points etc.

Now lets talk stability...
The team at Walmart built Hapi to run Black Friday traffic, stability and reliability were their main concerns. For this reason the framework does a lot of things extra such as limiting incoming payload size to prevent exhausting your process memory. It also has options for things like max event loop delay, max RSS memory used and max size of the v8 heap, beyond which your server will respond with a 503 timeout rather than just crashing.

Again, I don't expect this to just be an automatic "yes let's do this!!!". But considering there have been no issues opened on the topic, and I feel very strongly that this would be good for the community in the long run. I wanted to at least start a discussion on the topic.

[creynders]

Some other issues of interest: support for koa #1599, proposed package (plugin) structure #912.
If you have any suggestions on how to make this happen, let us know!
I think the most interesting would be to allow a dev to choose whether he wants to use express, hapi or koa.

[fiws]

I'm +1 this. I already missed the awesome hapi validation system a few times.
I know that I can use joi in express, but it's just not the same.

[ericelliott]

Can you get specific about extension points possible with Hapi that would be difficult or impossible with Express?

[ErikAndreas]

Given recent development around expressjs (expressjs/express#2844) and potential future e.g http2 molnarg/node-http2#100 - are alternatives to expressjs being considered?

[JedWatson]

@ErikAndreas the express project is looking in much better shape now that it's officially been adopted by the Node.js foundation. Aside from that, yes, we're keeping an eye on alternatives as they appear.

To give everyone an idea of where our head is at, however, we're more likely to break KeystoneJS down into a properly modular system. Whether the Admin UI even runs independently of Express should be a separate concern to whether Keystone's other core features could be integrated into any other node.js web server platform like Hapi, Koa, or any others that might become popular in the future.

In other words, instead of migrating from Express to Hapi (which would, regardless of benefits, be a massively breaking change) I'd rather make Keystone something that might spin up an Express server by default but also something you could plug into a Hapi project just as easily.

I'm going to close this issue for now - we're trying to get our (currently 518) issues under control and focus on the near future. It'll remain here for reference and anyone is welcome to add more information to it in the future.