Debugging Web Services

Glimpse is useful for analyzing and debugging your own Node server application, but what about 3rd party services? More often than not, we end up making 3rd-party API requests that are critical to making our own apps work correctly. Thankfully, Glimpse also gives us insights into all external web service calls our apps make, whether it’s from:

  • The server side, using request or http
  • The client side, using fetch or XMLHttpRequest

Web Services in theHUD

TheHUDwill display useful information about any AJAX calls made in the client, including:

  • URL (hovering will display the full URL)
  • Timestamp when the request was made
  • Request method (e.g., GET, PUT, POST)
  • Response status code (e.g., 200 OK)
  • Response body size (in kb)
  • Response duration (in ms)

To the left of the URL is a blue arrow, which is a link to that request in the Glimpse client.

Browser calls in the HUD.

Browser calls in the HUD.

Web Services in the Glimpse Client

Selecting the Web Services tab will display all web service calls made by both your server and client. You can filter between these by toggling the relevant filters for the types of requests you want to see.

Read the documentation of the Web Services tab for more information.

Debugging Web Services

Since Glimpse logs and makes information highly visible about all web requests that the client and server make, debugging web service calls becomes a lot easier. Common problems include:

  • Server errors (5xx) indicated in response
  • Expected web service calls never being made
  • Response not sending back the correct data, or wrong format for response body
  • Response taking too long

These can be hard to debug without knowing the details of every request and response. Here are some tips on how the Web Services tab can help:

  • See the original 5xx error responses (if any). Sometimes, when your app makes a third-party request that fails, it can respond with a generic 500 error to the client, leaving you wondering what went wrong. In the Web Services tab, you can:
    • Select the first call that fails
    • Open the response body details for that call
    • Read the original error response
  • Analyze the sequence of events/calls. The Timeline tab works great with the Web Services tab - it shows you each event that happened to make a specific request, whether it’s passing through middleware or calling web services. With this, you can see exactly which event or call failed before the expected web service call. If a prior web service call failed before that call:
    • Open the call in the Web Services tab by clicking that call in the Event column of the Timeline tab.
    • Analyze that call in the Web Services tab.
  • Inspect the Accept and Content-Type headers on the request and response, respectively. If the third-party web service properly implements content negotiation, then it should either return the expected Content-Type based on the Accept request header (e.g., application/json), or a 406 Not Acceptable status code otherwise.
    • Select the request in the Web Services tab.
    • Open the Headers section at the bottom for both the request and response.
    • Compare the Accept header in the request, and the Content-Type in the response.
  • Inspect the durations of web service calls. If a response from your server takes too long, it can be because of a bottleneck in the server, the web service, or both. You can determine this in the Timeline tab, and then, if a web service is the bottleneck, you can drill into this web service and determine possible solutions, such as caching responses.