Koa: Any plans to use eshttp?

[pyros2097]

Since koajs is going to be es2016 first class citizen, Do you have any plans to use this library which is also based on es2016 https://github.com/iefserge/eshttp.
It seems to have higher performance also.

[PlasmaPower]

The benchmark isn't really fair. In the benchmark, the eshttp response has already been compiled before the server is even started. In the real world, this doesn't happen as responses are dynamic. Even in cases of static responses, Node http responses can be precompiled too, but this isn't done in the benchmark. However, when I update the benchmarks to respond with Math.random() + '', eshttp wins by an even larger margin (4x). This is a very good reason to use eshttp.

The main detractor here is stability, maintainability, etc. Node's HTTP library will continue to be the standard library for a long time, with no breaking API changes. In addition, Node's HTTP library has been developed for a while, and has many useful features that eshttp is missing.

I'm not sure why what the library is written in mattes. Only the API, speed, and maintenance capacity matter.

I'm pretty sure we won't be using this for v1 or v2, as it is a breaking API change given the custom request and response objects. However, if this project takes off, the speed is a very compelling reason to switch. I started writing this assuming that the Node http module would be the fastest, but my testing has shown that eshttp is much faster, to my surprise. It should be noted that this project does not currently support piping from what I can tell. Piping is necessary for any Node.JS HTTP server, but it shouldn't be too hard to implement in eshttp.

[tj]

-1 from me, I think the elegant thing to do is stick with what's already provided in core instead of adding a large dep, the core http lib isn't really "visible" in Koa anyway

[PlasmaPower]

@tj Even giving up a 4x speed boost? Also, about the visible part, the Response and Request objects are visible, and eshttp gives up those in favor of a platform independent API. That's why this would be a huge change. However, it isn't ready for use in Koa yet, I agree on that. We should be following it though, it might be ready when Koa v3 development starts.

[PlasmaPower]

I also wonder why eshttp is so much faster. It still uses Node's TCP sockets, just with a custom HTTP compiler. I also wonder if Node's http could get those speed improvements without changing it's API.

[tj]

Yeah I don't like that it's another potential thing that people have to debug, without having the much larger Node core team to go to for http related bugs (if there are any these days). Perf is all relative, I think we do just fine there, real production deployments have at least 2 servers, so ~15k req/s, 5.4M requests per hour covers most people just fine :D

[dead-horse]

-1, not worth to do so, the http module is really complicated, and the core http module is much more stable. stability is more important than performance.

[PlasmaPower]

Yeah makes sense. I agree that stability is a big concern when using eshttp. I'll be keeping an eye on it though.

[pyros2097]

Yeah stablility is the most important thing. Anyway's atleast it has a really nice api to it. Maybe one day all of node's std lib will adopt es2016.

[PlasmaPower]

I don't see how es2016 adoption in core modules is relevant. What is relevant is promise APIs, which are in progress.

[jonathanong]

they should just copy node's API so that this doesn't even become a question

[PlasmaPower]

@jonathanong I agree, but I'm not sure if they can keep the performance boost without changing the API. If they could, then I'd just submit a PR to Node replacing their http module with the faster one since the API is the same.

[dead-horse]

I'll close this issue for now. we won't use eshttp in the near future.