0

In a bit of a dilemma. At work we are having issues with an API service that communicates with the client side through a WebSocket. The problem so far is that the WebSocket seems to be unreliable. We have sufficient logs that tell us this, but for some reason everyone is on the boat about adding logging to the front end to see what is going on.

I have a couple of issues with this:

  1. Unnecessary traffic. Logs are collected in the backend, so to log from the front end, I'd have to create a new api endpoint just to log front end code.

  2. We already know the problem is with the WebSocket, why spend time and effort on logging the front end? (Other client apps also face the same issue). We're already logging when updates are being sent.

Pros:

  1. I guess more clarity as to what is going on?

Note, we already log JS console errors and exceptions.

Can this be considered too much logging? Or am I not seeing something?

  • From your question it is not quite clear if you only know that there is "something" wrong with the WebSocket, or if you know what precisely is wrong, and how to solve the problem. If it is the latter, why bother with further logging at all? But if it is the former, why do you think front end logging cannot provide additional information? – Doc Brown Mar 4 at 9:02
  • I feel as though front end logging won't provide much. It'll be something like "Backend sent this status" and then "front end received this status" which as someone else pointed out is just noise. We already have logging for "back end sent this status", so why is it necessary to validate that status was received? We also know where it fails, we just don't know why – Pants Mar 4 at 14:16
  • "WebSocket not reliable" sounds to me like you should expect to get log entries "Backend sent this status" with no corresponding "front end received this status". Is that correct? So from logging both backend and frontend, you may get a statistics how often or under what specific circumstances the communication fails. Or will you get that already only from backend logging? (Since I don't know your system, and the information in your question is IMHO not very detailed, I am just shooting in the dark here).Maybe you can clarify things a bit? – Doc Brown Mar 4 at 14:51
3

It is all about trade-offs.

  • can you store client-side logs?
  • for how long?
  • do you scrub private data?
  • can you send the complete log on error?
  • does the app send requests for all actions?
  • can you figure out user actions when they don't send network requests?

There are very good use cases for collecting client-side logs, especially when trying to reproduce failure scenarios. Examples:

  • your app / browser crashed, would you like to send a report?
  • rage shake, I think something is wrong, report error.

The number one argument for client-side logs is that not all user actions / state updates on the client result in a network request, so the server never has the whole picture.

People already do that and some libraries make it easier than others; e.g. React + Redux. If you check out redux-devtools, you will see that you can do action replay . Why? Because all state changes are handled in similar fashion.

too much logging?

I articulated the previous text around state changes. When logging some information that is not directly related to a state change, that is just fluff. The same way you remove print statements everywhere before putting it in prod, you can remove / consolidate log statements that are not essential.

  • is the log record related to a state change?
  • is it related to necessary implementation detail?
2

Why are you doing logging? One reason is on the backend to have forensic evidence about attackers, we can ignore this. The other reason is to find hints what is going on if something goes wrong within your software, preferably after the fact.

What you really want (and can't get obviously) is one single line in the log that tells you exactly what was going on. Second choice, which is what you should aim for, is enough logging so that you can identify a fault, but not so much that you are looking for a needle in a haystack.

Blindly logging everything isn't going to help. The frontend should have logging to help find problems with its own behaviour, and it may be useful to log when the frontend detects misbehaviour of the backend. You'd probably want to invest some effort into this. Logging "I sent request X to the backend", then "Backend responded to request X just fine" is just useless noise. You'd want to collect info locally, then if you get an incorrect reply from the backend log everything that happened on the way (because in the end, the incorrect reply could be caused by an incorrect request).

  • That's what I'm saying. We're already logging "Websocket is sending this status" I don't think it's necessary to log "Received this status" in the front end because if status was received then everything would work as expected. The problem is, if status is sent but client side doesn't receive it, we have no way of knowing. But then again, in theory, if the web socket goes down there should be an exception on front end thrown. – Pants Mar 3 at 22:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.