Closed nbibler closed 2 years ago
Oh... hrm... big difference between the createServer
implementation and my minimum-viable middleware implementation is the missing app.use(express.json())
. That seems to make a significant difference... if that middleware is prepended before the createMiddleware
call, then the request handler gets request.body
data. Without it, the route handler gets undefined
.
Hey, @nbibler.
I believe that the intention behind createMiddleware
is to delegate any request/response body parsing to you, as you're integrating it into an existing server. This library shouldn't make assumptions about how to parse bodies.
That being said, if we can prepend an express.json()
parser middleware to the middleware function returned from createMiddleware
, it'd be great. I don't think that's possible with the Express API, is it? Unless we return a list of middleware and ask the consumer to spread it:
app.use(...createMiddleware(...handlers))
But, honestly, if you're expecting request/response JSON bodies, you should be using a JSON parser middleware anyway.
app.use(express.json())
app.use(createMiddleware(...handlers))
In the same way you may be handling different response body types, which would require a custom parser middleware on your side.
I'm not convinced that this is an issue on our end but I'm happy to continue the discussion.
When using this library, I've noticed a behavior difference between
createServer
andcreateMiddleware
. I think it's a bug increateMiddleware
.Using identical handlers, the createServer implementation will provide a
request.body
to the handler function, but createMiddleware will always returnundefined
forrequest.body
.There is a minimum-viable example gist here: https://gist.github.com/nbibler/5f08424bc8411b87acc8e8f906dfdf5d