Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Dylan Piercey
    @DylanPiercey
    Alright, i've got to go, chat with you all later!
    @DylanPiercey laters
    Rick Medina
    @rickmed
    @hnry question: how do I return a response to the client from the upstream (the function with the req param)?
    do I need to go through the whole middleware chain any how?
    hnry
    @hnry
    @rickmed this is without spirit-router?
    @rickmed you would use response(), or file_response(), err_response(), redirect(), from spirit.node
    important to know that a response is just a small hash { status, headers, body } so you can return { status: 123, headers: {}, body: "Hello" } which is the manual way of making a response
    all the response() and file_response() functions i mentioned are just helpers to help make that small hash
    Rick Medina
    @rickmed
    I don't follow... What I mean is something like:
    
    (handler) => {
      return async (request) => {
    
        const userExists = await calltoDB(request.user)
        if (!userExists) // return "you have to login!" immediately to client
    
        return handler(request)
      }
    }
    @hnry
    response() does the same thing as the bottom example, except response() also gives you helper functions
    a valid response (not the function) is just saying { status: 123, headers: { ... }, body: "..." } you get it? but people might find writing it the manual way tedious so that's why i included functions for creating it like response()
    Rick Medina
    @rickmed
    yes yes, I'm super clear about the response_map and the helper functions...
    I was just wanting to clarify how the return response() vs return handler(req) is managed internally with the compose promise reducer
    @hnry
    hnry
    @hnry
    oh the reducer (spirit.compose) doesn't actually call your functions
    you are calling them when you say handler(req)
    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
    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