it simply calls the outer function:
(handler) => { // <---- spirit calls this function
return async (request) => { // <-- this is the result of handler(request) / the previous middleware
const userExists = await calltoDB(request.user)
if (!userExists) return response("you have to login!")
return handler(request)
}
}
so if you return early like in the example, it doesn't call the next middleware/handler, and so it just unwinds early
bc the reducer is calling all the function no matter if they return a value (eventually transformed into a promise) or handler(req)
oh
if not that's ok, i have an idea of what you mean and can look into it still
are you sure your condition is working ok?
everything must be fine then, sorry...
thank you
versus instead of running once only
As for production ready, yea I believe so, but the parts that I haven't tested thoroughly is proxy forwarding and there's no built in etag generation (but can always add your own)
@hnry @dodekeract in a vanilla node server response there is a
sendDate property which you can set to false to disable this header. Don't recall how to access the vanilla response with spirit though, @hnry?
And the main middlewares like body parser and cookie session support I re-used express versions is because of time. I've tried reaching out to some of the authors to see if they can just provide the lib or some lean version of their lib without the express parts and usually that doesn't go anywhere.
Which is cool, but yea I think the body parser can be faster than the express one, but just time and priorities of what to focus on
export default handler => request => {
return new Promise((resolve, reject) => {
const req = request.req();
const chunks = [];
req.on('data', data => {
chunks.push(data.toString());
});
req.on('end', () => {
request.body = chunks.join('');
console.log(request.body);
resolve(request);
});
});
};
Technically there's a performance hit in general when using middlewares in spirit just like in express, but in different areas
Also a slightly modified version of the code I posted above works pretty well. Does everything I need it to. :smile:
You mean with the wrapper? Yea, spirit + express body parser vs express + express body parser, spirit version should win from what I remember, there's just way too much other stuff in express that causes overhead (point of my article was implementation as a whole rather than micro optimizing) so don't try to micro small details unless you can reap a structurally benefit
I could replace both the wrapper and express body parser with like 15 LOC.
Also I think this should be faster. I won't benchmark it, but it's as minimal as possible from what I can tell.
I think those are the major points really and error handling
One thing I noticed - the
request.req() generates a huge object. Is there any more efficient way to just get the body's chunks? There seems to be a lot of overhead just from that one call. Would be awesome to be able to avoid it.