Yes. The intent is to provide a resource through the API to deliver the data needed to produce reports/graphs in the client (browser). If in the future we need to protect the server from servicing too many calls, we could cache the data (either in an internal table or, more likely, just using nginx caching for the resource).
The main point is to inform the client/user when an error has occurred. If there are SQL failures, then “Unable to retrieve xyz from the database” or simply “An unexpected database error occurred. Please ask an administrator to check atlas logs at YYYY-DD-MM HH:MM:SS for more information” may suffice. What currently happens if you force one of those SQL calls to fail? I’m assuming that the http request will either hang & timeout, fail with some default express failure message, or – worst case – return as 200 OK without the expected result. I haven’t looked at them all, but wouldn’t be surprised if there are situations where subsequent code would be executed inappropriately because we don’t return after logging these errors and many are nested several layers in if/then/else conditions where it might not be able to see whether the console log line will be the last line executed in the method.