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.
Keep me updated on how it works out for you and if there's things that can be improved 😀
@diogoazevedos still around to fix bugs etc. spirit is pretty complete (core of it, aside from running in on the frontend). middleware like generating a etag or other helpers, i'm leaving that up to users to do, since usually they are user specific or very easy to write a generic one
open to features / contributions as always if you have anything i never thought of
@hnry glad to hear that, we're using spirit for our node servers in production right now. It's amazing how simple and minimalistic it is. :)
Only thing I'm wondering so far is how to modify the default "error -> stack trace" behavior, preferably without middleware and instead replacing it where it's invoked.
Resoning for that is that leaking stack traces in production isn't a good thing to do and middleware seems to be relatively taxing.
also another way is to write a middleware that will catch all unhandled or bad responses right before it goes back to spirit
something like this, https://gist.github.com/hnry/c0a153b2df676b4b8ef3109925bc609e (just put it together real fast as an example)
there's a snippet here about it too http://spirit.function.run/error-handling.html#catch-all but that won't check when something keeps passing along a bad response use
spirit.node.is_response for that to check, but if you don't care about setting a custom error message for specific or generic things, then the easiest way would be to set the NODE_ENV to production and it won't dump the stack for 500 responses
Hi!
First of all, thank you for the great library, I really like it!
I was inspired by it to write my own router, just because the API felt more natural for me. Wanted to share it here to get your thoughts:
https://github.com/fabiocbinbutter/spirit-guide
First of all, thank you for the great library, I really like it!
I was inspired by it to write my own router, just because the API felt more natural for me. Wanted to share it here to get your thoughts:
https://github.com/fabiocbinbutter/spirit-guide