functions-framework-nodejs
functions-framework-nodejs copied to clipboard
Custom Middleware
It's unclear to me whether middleware can be customized, and if so, how. Please document that.
It seems that you are adding some middleware at https://github.com/GoogleCloudPlatform/functions-framework-nodejs/blob/5f2fecf681783d5c07a656526f4639f57a127a91/src/server.ts#L87-L94 but I see no way to add my own middleware.
Hey Lorenz, did you ever figure this out? I'm scratching my head at how to do this.
No. In my particular case, I managed to implement a workaround based on req.rawBody, but of course, this might not be helpful in your case, and it certainly is not a good replacement for middleware...
I just found that ‘app’ is actually passed down as a property of req. Too late here for me to actually try it out but maybe that will work.
Perhaps this blogpost may help:
https://medium.com/google-cloud/express-routing-with-google-cloud-functions-36fb55885c68
We don't explicitly allow you to customize the express object / interface though, so ymmv.
A code sample for what you're trying to do would help.
This is also causing a problem for me; The client (which I don't control) sets the content-type to application/scim+json - I can't add a bodyParser for this type since the bodyParser.raw is hit first.
A potential fix would be to change the type in the options for cloudEventsBodySavingOptions to application/*+json - This will catch any json encoded application
Hei @grant, I would help to create documentation about custom middleware, should I create docs/middleware.md ?
Hei @grant, I would help to create documentation about custom middleware, should I create
docs/middleware.md?
Sure, PRs are welcome 😊
If we have more information on what the ideal experience should be, would like to see that too.
Thanks for the requests and comments here, everyone!
Unfortunately, exposing custom middleware is not something that we're going to take on because it risks permanently tying us to the underlying HTTP implementation. By keeping that hidden, we can ensure the experience of writing and deploying functions is relatively stable even if we change up the backing implementation.
If you have specific use-cases we can try to help with, let us know with additional issues -- it seems like the request body verification issue has already been solved.