As a developer myself, the most complicated part of the job is not writing the code but reproducing an issue the customer reported, debugging, and fixing the issue. With such little information at your disposal, it becomes a nightmare to start debugging the issue, let alone fixing it. Can we do something better here?
Well, that is when Zipy comes into the picture. It lets you easily view the issues that have occurred in the customer's environment and provides you with many insights that can help you significantly reduce the time to fix a bug. One such feature is the Network section in the dev tools that can quickly help us detect if there is any issue in the Network event.
Out of the blue, a customer reports an issue where they are facing a problem with a particular flow. And you, have no clue how did this error occur. Is it an API request failure? Is there an issue in customer environment? Or is it the browser cache? Debugging such an issue can become a challenge.
Use of network logs in Zipy. You can view the network event by clicking on the Open in Dev Tools link in the breadcrumbs of the session replay. That opens a new section right below the session replay where you can view the Network events, Console logs, and Stack traces. Our area of interest for this blog is the network tab which has the details of all the Network calls in the session like Headers, Timestamp, Status, Type, and URL.
In the headers section, you can view all the types of Headers of the API call like Request, Response, and General Headers. The request header parameters are pretty handy to debug issues related to the APIs invoked from the client-side. For instance, the following screenshot request-id header is the one that will be available in the backend logs. We can use the request-id that is unique for a particular user, to search logs in the Log search engine like Splunk, CloudWatch, Elastic Search, or any of your log servers.
Zipy does not capture the request payload by default. However, please contact our support team to enable such a setting if you need the payload information. For example, if you log some custom parameters from the request payload, you can reference the network payload events to track the logs.
Using Zipy’s user session replay along with the additional information in the breadcrumbs/network tab can give developers the most critical information they need to analyze issues that the customers have reported. Using API headers can be pretty powerful to search the logs in the backend effectively. It can reduce time and effort and provide some interesting insights to help resolve issues and even proactively fix bugs.
Feel free to comment or write to us in case you have any further questions at firstname.lastname@example.org. We would be happy to help you. In case you want to explore Zipy for your app, you can sign up here or book a demo here.
It is no less than a nightmare when a feature request from the product team is not getting fit with the current system. So this feature request required some heavy aggregated functions which did not give satisfactory results with a row-based database.
Continuous Integration and Continuous Delivery (CICD) are terms used to describe a process where multiple changes are made to a codebase simultaneously. In very simple words, CI is a modern tool for development practice in which code changes are made frequently.