Is there a way to generically log a response?

[ddevienne]

I've added basic logging to my HTTP REST API server using uWebSocket:

    void addServerTimingHeaderLibPQ(uWS::HttpResponse<wSSL>* res, const pq::ResultSet* rset) {
        ...
        auto metrics = fmt::format(
            "db;dur={:.3f};desc=\"...\"",
            dur_millis, exec.count_, rows, cols, elems, sent, recv
        );
        res->writeHeader("Server-Timing"sv, metrics);

        fmt::print(os, "{} {}< {}\n", now(), res->getRemoteAddressAsText(), metrics);
    }

But this lacks HTTP status, byte size sent, number of headers, etc...
Obviously I know about those things in specific handlers, but I have many of them,
and was hoping to centralize that generically, and looking at the API, it does not seem possible as-is.

Am I missing something? Any chance more info into the response would be possible?

PS: BTW, addressAsText() should be static and public IMHO. I plan to do logging using a SPSC lock-free queue, and instead of transporting the whole text address, use the 16 byte binary one and do the text conversion in the other thread. So I'd like to use addressAsText() directly, instead of duplicating it. FWIW.

[uNetworkingAB]

There is no logging because logging does not belong in a server library. If you want logging you can log whatever you want, using whatever logger or monitor as you want, as things happen. Logging is a separate problem, for a separate library.

Logging is like religion - you can never get people to agree on anything so that's why it is kept as a separate problem to be solved according to policies of that company, in their ways. Logging is also extremely slow and often times make up the majority of overhead.

We don't keep track of headers written, you have to log them as they are written in your wrapper if you want to.

Moving data across threads is making your app slower, not faster.

[ddevienne]

Note that I wasn't asking about logging in the library.

I was asking of keeping a little more state in the response that the code doing logging (outside the library) could access.
Not much, how many bytes written, the status (just as a integer), how many headers (and perhaps headers bytes vs body bytes).
Or if I really want it generic, I need to use the HttpResponse<>::onData() hook?

Regarding threading, doing file IO in the main uWebSocket thread doing socket IO is not a good idea IMHO.
Having a single additional thread doing the logging file IO (and string formatting) fed via a fast lock-free
SPSC queue (with 100M+ msg/sec throughput) helps uWebSocket remain fast. But you'll probably disagree :).

In any case, unless I missed something, addressAsText() can be static. And having it public would be helpful. FWIW.
Otherwise I'll just reimplement or copy/paste it I guess.

[uNetworkingAB]

Logging statistics must not add any overhead to the library for those not using logging. So if you want those statistics you have to keep them yourself as you add headers and receive body. There is no need to have the library track various statistics for those who don't want it. You can attach any user data to your response as you need.