Today I continued work on a nicer log display. Right now we have a route for our Get API that queries the database and the file system of the EC2 instance for all errors that were logged from every part of our application and displays them. It’s a ton of information, and it’s all jumbled together and displayed on the DOM at once. This slows it down. You click on a tab (the only organization it has) and it hangs for a few seconds while it adds all the data to the DOM. I’m writing new API end points for the Get API. The errors will be grouped, and one end point will query for and display just the summary of information about the errors (counts for each error type, ratios, etc), and the other end point will get the actual errors to display. I might use React components for this or just plain JS if it doesn’t need much.
The result will be something that can show you useful information about the kinds of errors it’s experiencing without having to download them all. The interface will be snappy. It will be a more useful tool to use to develop and for anyone to observe in the future after launch.
Some challenges I had developing this were wrapping my head around the kind of data the API end points need to send to the browser. It took me a while to realize that less is more. The summary end point should not even display any errors at all. I also had to think carefully about how to categorize the error types and what that mean for the MongoDB query syntax.