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
    so if you return early like in the example, it doesn't call the next middleware/handler, and so it just unwinds early
    Rick Medina
    @rickmed
    I did a test, as I suspected, the response is done correctly but the middleware chain is still ran all the way
    bc the reducer is calling all the function no matter if they return a value (eventually transformed into a promise) or handler(req)
    hnry
    @hnry
    that's a bug then, i'll have to take a look, do you have a small example i can see?
    oh
    if not that's ok, i have an idea of what you mean and can look into it still
    Rick Medina
    @rickmed
    just have an early mw return respond() and do some side effect with a later mw like log and you'll see
    hnry
    @hnry
    ok
    hnry
    @hnry
    i can't reproduce
    are you sure your condition is working ok?
    Rick Medina
    @rickmed
    super weird, I deleted the first test and then tried to recreate it unsuccessfully -scratching my head...
    everything must be fine then, sorry...
    hnry
    @hnry
    @rickmed no worries, it's helpful still to double check for my own sake ha
    thank you
    hnry
    @hnry
    @rickmed by the way, i think i see what you were saying, found an issue closely related to what we were talking about...
    Right now there's an issue where:
    (handler) => {
       // code here always runs (but it shouldn't)
        return (request) => {
        }
    }
    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
    👍