I spoke to @dodekeract in gitter, to recap some main points from there:

I know most of this discussion comes from the article I wrote about spirit performance.

Good fundamentals, not micro optimizing

The article was about how structural changes / implementation as a whole can affect performance. And as along as you come into designing something with good fundamentals, you get good results (ie: never wrote spirit to be fast, it just happened that way).

Remember not every request has a request body.

'Native' vs using spirit-express

A 'native' body parser would be nice (it is on my list of todos). The performance difference between using spirit-express and it just being native is really small. Any performance benefit comes from rewriting the core functionality from whatever express middleware, and not so much from not having to use spirit-express.

My issue with spirit-express was never the performance, that's why I quote the word "native". That word in general makes it sound much faster haha. But my issue was you lose out on the benefits of spirit, (testability, thinking about a request / response as being transformed vs changes being crammed onto a req / res object).

Middleware is slow anyway

Using middleware in express or spirit or anything else will take a hit in performance regardless of what the middleware does. Reason usually varies for that project. For spirit, it's because of Promises (or enforcing use of Promise). Remember also in spirit middlewares return, they rewind back vs callback based of only 'going forward'.

Is middleware use slower than express?

No, it's still faster.

I got a lot of comments for my article about why I didn't test using middleware / logic. And I didn't understand the point of it.

If I tested spirit and express and had the test both use the "body-parser" module, what's the point of it? The body-parser performance is relative to itself and not to spirit or express. So if spirit is faster than express, using body-parser, passport, or whatever else, you would see the same results.

Informal Benchmarks

Informal meaning I just put it together real fast to show my point:

Every request is a POST with a small body.

spirit + body-parser via spirit-express:

Running 7s test @ http://localhost:3001
  8 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.56ms    1.49ms  15.26ms   88.96%
    Req/Sec     1.09k    86.73     1.27k    80.18%
  60761 requests in 7.03s, 9.62MB read
Requests/sec:   8642.64
Transfer/sec:      1.37MB

express + body-parser:

Running 7s test @ http://localhost:3001
  8 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    15.43ms    3.86ms  80.71ms   95.77%
    Req/Sec   394.38     56.74   464.00     91.79%
  22036 requests in 7.02s, 4.75MB read
Requests/sec:   3138.56
Transfer/sec:    692.69KB

Results

Both spirit and express take a big hit when you use a middleware (body-parser in this case). Is it because of body-parser ? Yea because it's not a cheap operation, but also you have to pay a price for just using middleware in general.

This ended up being long haha, maybe I'll convert it into a follow up article / post. Also I do think the body-parser can and should be re-written. I think the performance difference would be minor (when compared to the grand scheme of things), but still worth the effort as it's a small project.

from spirit.

Um, there is an example.

from spirit.

@Lichtjaeger Sorry, didn't specify that I meant without the overhead of wrapping it with express. I'm not using spirit so that I can use express, if you get my point.

I found out how to do it in the meantime. It can be assembled by writing a custom middleware that reads the request's req function and assembles the chunks. I'll probably make a body parser module for spirit later.

from spirit.

OK, explanation time.

The sprit-express-module is not an express-server. It only wraps express-middleware to spirit-middleware (~250loc uncompressed and commented).

You can use any express or connect middleware in spirit through sprit-express.

Interesting is the line route.post("/", ["body"], example). Here in the Array in the middle, you define that you will use "body" (aka request.body) as the first argument of the example function/handler.

from spirit.

Does this work with binding to a single route? It'd still be a significant performance hit when I bind it to all routes. Not having the bloat of req and res is one of the reasons why we're using spirit in the first place.

If every route gets wrapped with the express sugar I'd expect spirit to perform about as "bad" as express.

from spirit.

Also, I actually fixed this in the meantime by implementing a small body-parsing middleware as a "native" spirit middleware. I may publish it later on, depending on how much time I can spare and if the company is fine with me doing that.

from spirit.

You can add a middleware to a specific route or route-group using the wrap function. (documentation)

Spirit uses nodes "http"-module. So req and res are still there (in the background).

It would be nice if @hnry could say something about performance and comparison with express.

from spirit.

Thank you. A very good statement.

from spirit.

Closing in favor of dodekeract/spirit-body.

from spirit.