A small part of your Meteor project are a handful of webhook URLs. Relatively simple endpoints that will be called by external systems with a (most often) HTTP POST request.
To make it easy for external parties to debug connections themselves, we want to be able to show the comings and goings of those URLs. Our idea was to create a middleware limited to the webhook endpoints where we would serialise and store both the IncomingMessage and ServerResponse.
But I got stuck trying to serialise the ServerResponse. OutgoingMessage is a Writable and it does not seem like I can setup a pipe or anything else to capture the response body.
Looking at different connect middleware the only one that seems to even dare touch the response body is Express’ compression. This seems to work by creating an entire proxy ServerResponse object to be able to intercept all writes.
I tried writing the simplest implementation of this that I could think of in a middleware, code below, but it is only logging gobbledygook.
Has anyone tried to capture the response from Meteor in as late a state as possible? Any tips?
The reason we are looking at doing it this way is because different parts of the full request handling might throw a Meteor.Error along the way. We want to log as close to reality as possible: what exactly did Meteor end up sending to the requestor. Not just log what we think the response body from our inner function would be.
The failing proof-of-concept:
export const middleware: NextHandleFunction = (req, res, next) => {
const _write = res.write;
res.write = (...args) => {
console.log(args[0].toString("utf8"));
return _write.apply(res, args);
};
next();
};
Another thing I was thinking about: maybe what I describe as gobbledygook could actually be gzip compressed output? Is it possible to insert my middleware at a step before Meteor adds this? Even Meteor.startup() seems too late, e.g.:
Meteor.startup(() => {
WebApp.rawConnectHandlers.use(middleware);
});