Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    hnry
    @hnry
    versus instead of running once only
    Rick Medina
    @rickmed
    maybe that's how I found the issue back then...
    hnry
    @hnry
    i think so :)
    Florian Wendelborn
    @dodekeract
    Do you think this module can be called "production ready"?
    Florian Wendelborn
    @dodekeract
    Oh, also - is it possible to remove the Date header?
    hnry
    @hnry
    @dodekeract hey! The date header gets added by nodejs by default not spirit, so I don't know off hand, but I'm sure there must be a way
    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)
    Dylan Piercey
    @DylanPiercey
    @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?
    hnry
    @hnry
    Thanks for that @DylanPiercey , I'll have to add support for that
    Dylan Piercey
    @DylanPiercey
    No problem, glad to help.
    Florian Wendelborn
    @dodekeract
    How is body-parsing done in spirit? If it's using some express middleware - is there an alternative? I avoided express for a reason.
    Dylan Piercey
    @DylanPiercey
    @dodekeract just curious what was the reason?
    Florian Wendelborn
    @dodekeract
    IMHO it's too blown and therefore slow. If the middleware compatibility layer has to add all that complexity then it's not worth it to use a middleware.
    hnry
    @hnry
    @dodekeract yea I agree, sorry for the slightly late response. Well middleware in spirit is different because really you are just transforming the input and output (request /response) instead of trying to manipulate objects compared to express
    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
    Florian Wendelborn
    @dodekeract
    @hnry how do I get the necessary information to parse the body myself? What scope does the function need for that?
    Florian Wendelborn
    @dodekeract

    Can anybody tell me where I can find that information? I really need to parse request bodies. :worried:

    If that's really not easy at all - how taxing is using the express wrapper? Can I only use it for a single route? (and how would I do that?)

    Florian Wendelborn
    @dodekeract
    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);
            });
        });
    };
    Florian Wendelborn
    @dodekeract
    resolve(request) should be resolve(handler(request))
    hnry
    @hnry
    @dodekeract it's a pretty thin wrapper, you should just use it. You'll get hit by a "tax" in a lot of ways anyway. That's why I didn't focus on it
    Technically there's a performance hit in general when using middlewares in spirit just like in express, but in different areas
    Florian Wendelborn
    @dodekeract
    It should overall be less lost performance though, right?
    Also a slightly modified version of the code I posted above works pretty well. Does everything I need it to. :smile:
    hnry
    @hnry
    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
    Florian Wendelborn
    @dodekeract
    Yes, I know micro optimising often isn't worth it. I'm quite happy that I can avoid the additional dependencies though.
    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.
    hnry
    @hnry
    Ok sounds good 😀 if it you have a specific use case, but keep in mind there's size implications like you don't want to go through a giant request body, and how to parse the body (json, text, urlencoded)
    I think those are the major points really and error handling
    Florian Wendelborn
    @dodekeract
    I only need JSON, since it's for a REST API that doesn't use anything else. I'm aware of the body-size limit, but AFAIK it's the same problem with express. We have a reverse-proxy that will limit the size too - so it shouldn't be a big deal.
    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.
    hnry
    @hnry
    That returns the original nodejs req object ( its naturally big )
    Florian Wendelborn
    @dodekeract
    So it doesn't create a new one? That's good. Then there shouldn't be as much overhead as I expected. :smile:
    hnry
    @hnry
    👍
    Keep me updated on how it works out for you and if there's things that can be improved 😀
    Florian Wendelborn
    @dodekeract
    Will definitely do. Thanks for the nice and fast HTTP server. :clap:
    Diogo Azevedo
    @diogoazevedos
    @hnry This project still active?
    hnry
    @hnry
    @diogoazevedos i'm still around yea
    @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
    @hnry
    oh actually, i never finished allowing users make a custom return of their own, ex: return { file: "index.haml" } can be valid if a user set it up to understand that
    Florian Wendelborn
    @dodekeract

    @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.

    hnry
    @hnry
    @dodekeract if the NODE_ENV is set to "production" it won't dump the stack trace, just has a 500 response with no body, did you set NODE_ENV for your production for example NODE_ENV="production" node server.js
    also another way is to write a middleware that will catch all unhandled or bad responses right before it goes back to spirit
    hnry
    @hnry
    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
    Florian Wendelborn
    @dodekeract
    @hnry it should be set to production. I'll double check all of this. Thanks for the info/help!
    hnry
    @hnry
    no problem friend :)
    fabiocbinbutter
    @fabiocbinbutter
    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