Provide an optional endpoint for logging Javascript errors

[sdeleuze]

When you are building a Java + Javascript based application with a significant complexity on client side (Angular, Ember or React application), a big issue is that you have no idea of the errors that occur on client side.

A good solution I have already experimented on big projects is composed of 2 parts:

• Client side: a Javascript file intercept invocations to functions like console.log() to send an HTTP request/websocket message to the server with the error
• Server side: A REST/Websocket endpoint receive the error message (usually a JSON object), parse it and print it to the log with the same level (DEBUG, INFO, etc.) used on the client.

It should be possible to change the client log level you send to the server dynamically.

This is a little bit more a client/server integration thing than usual, but on the projects I tested that it was just hugely useful some I think we should provide this in Boot. I will be happy to contribute a PR if you think this is something interesting.

[jchesterpivotal]

This would definitely be helpful for us. We have a large suite of Selenium tests. We've not found a happy and stable way to fail the tests when a javascript error occurs.

[jeanbza]

👍 this would be hugely helpful. As @jchesterpivotal said, we also have selenium tests, and we also have no great way other than to try and replicate locally.

[sdeleuze]

Please find in this gist a sample client side implementation. I do not expect we reuse it exactly as it is, but it is IMO a nice starting point for experimenting and discussing.

Any thoughts?

[philwebb]

@sdeleuze I think we should look at this for 1.4 as we're close to feature freeze on 1.3. It's a really nice idea but I think we're just going to run out of time for 1.3.x :(

[dsyer]

Someone could take Sebastien's code and publish it as a jar that anyone can consume in 1.3 (like I did with Jersey in 1.1). Then we can get people using it and build the features up for 1.4.

[snicoll]

👍

[sdeleuze]

I totally agree, any javascript code provided with Spring Boot will require a lot of testing with many browsers, so targeting 1.4 will allow us to get feedbacks, improve this draft implementation, etc.

[philwebb]

Given all the testing that will be required I think it's best if we push this back to 2.0 where we can get it into an early milestone.

[szmeti]

We have also experimented with client to server logging on our projects.

A few things that you might want to consider:

1. You do not want to overload the server with countless log messages. This can happen in various circumstances (bug that affects all clients, etc.). To avoid this we have implemented the following mechanisms:
   • Batching requests (send x number of messages at a time)
   • Throttling: Server can respond to the requests with 'slow down' or 'stop sending' messages, which causes the clients to dynamically adjust the rate at which they are sending log messages.
   • Maximizing the number of messages in a single request.
   • Configurable send trigger: wait for x messages and then send or send periodically regardless of the number of log messages.
2. In many cases a single error message does not give enough context information to determine what was actually causing the error. To make debugging easier, we introduced a client-side cache that collects all log messages regardless of the log level (DEBUG and TRACE as well). This cache is essentially a circular buffer with a configurable size, so it only keeps the last x messages in memory. With this in place, you can configure the module to send the content of the debug cache as well when an ERROR message is triggered. This way we can see what happened on the client before the ERROR occurred.

I might be able to contribute to this PR. Although our implementation is fairly specific to a given environment (TypeScript), it should not be a huge effort to convert parts of it to native Javascript.

[sdeleuze]

Hey @szmeti, I would be very interested to see your TypeScript version if possible.

[szmeti]

Hi @sdeleuze,

I only found some time today to respond to this. I have created a gist with the code: https://gist.github.com/szmeti/5eefe2719eb54ea0276eb64c7c4c2097

I added some comments to the code and you will need to get familiar with the loglevel library (https://github.com/pimterry/loglevel), because we used that as the underlying logging framework. Otherwise, the code is pretty straightforward I think.

[ghostd]

Hi,

One year ago, i made some experiments to "unminify" the sources on the server side. The client sends the stackstrace to the server but if the source is minified, the logs are not "ready to debug"; you need to use the source maps to read them.

Here is a POC (all comments are welcome :-) :
https://github.com/ghostd/spring-boot-source-maps-example

Reagrds

[philwebb]

In hindsight this is likely to add complexity to the code base that we don't really want.