Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    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