Debugging your web GIS applications – Leveraging your browser’s developer tools

As Software as a Service (SaaS) offerings and Web GIS applications become more robust, they also become more complex. Understanding how, as builders of these applications, we can efficiently and effectively debug issues our clients may be having with these applications is becoming more important. There are many tools at our disposal as web GIS developers which we can rely on to help understand why problems arise and potentially how to fix them. In this blog, we’ll cover our browsers’ developer tools to read errors and understand network traffic between the client (browser) and our data stored in our Web GIS. Let’s get started!

SaaS offerings and Web GIS applications have become more robust and more complex. This, and the desire for our clients to have more information available to them, means that our applications we build can become extensive and expand over time. This may present challenges for our clients when viewing these applications in their browser. Sometimes they may be forced to login when the application should be public. Other times they may see errors that a layer is unable to load. Sometimes, no errors appear at all but nothing is visible in the map. Many kinds of problems can arise which may be difficult to explain at first glance. How can we quickly determine why our clients are seeing these problems? We can leverage our browser’s developer tools.

Where can I find my Developer Tools? 

All modern browsers have their own built in developer tools. No third-party plugins or applications are required to leverage them. Depending on your browser, they are all accessible in a few different ways.  

Chrome DevTools can be opened using a keyboard shortcuts F12, CTRL+SHIFT+I and by navigating the menu interface via Options, More tools, Developer tools or as displayed in the picture below: 

Firefox Developer Tools uses the same keyboard shortcuts as Chrome, using F12, CTRL+SHIFT+I, or by navigating the interface via Options, Web Developer, Web Developer Tools, or as displayed in the picture below: 

Lastly, Microsoft Edge, as the others, uses the same keyboard shortcuts of F12 and CTRL+SHIFT+I and by navigating the interface using Options, More tools, Developer tools or as in the picture below: 

At first, the amount of information displayed in the developer tools can be intimidating. We’ll go through which information is the most valuable to us as web GIS developers. This will help us become more familiar and comfortable working with the dev tools and help us debug our applications quickly. 

Reading the Console tab: 

The primary source of information for us in the developer tools is in the Console tab. The console tab in our case serves one use: viewing logged messages. The console tab can contain errors, warnings or logs from the application. Most times, if the application is failing to load or is presenting strange behaviour, the console can explain it.  

Warnings (in yellow) are usually an indication that an issue in your application may impact your client’s experience and use of the application. They do not necessarily mean something is wrong. Sometimes they can be ignored and will not impact the behaviour of the application within the browser. Warnings should be noted and compared to the problem your client is experiencing and may be worth investigating if there are no more specific messages.  

Errors (in red), however, are almost always important and should be resolved. They often explain, in detail, exactly why the application is not working as you or your client is expecting.  

The advantage of the console is that it will provide more information as to why the application is not loading or working correctly. It will almost always provide more information than the application can provide about an error and should be used often for resolving issues with our web GIS applications.  

Reading the Network tab: 

The secondary and equally as important tab in our developer tools is the Network tab. This tab contains all of the network requests made by your client’s browser, through your application, to the servers hosting and storing the data it displays. Most times, it will also include the response from the server, indicating to us whether the server was able to respond, and if it has returned the correct information we expect. 

Our application may not present any errors or warnings in the console tab but may still not behave correctly. In these cases, we should look through the network traffic for more information. 

This network tab will contain much more information than the console tab but is equally as valuable if we know what to look for.  

Our first instinct is to look for status codes showing error messages, like the console. This is not the best approach. Often the server will respond to the client request, showing a status of 200. However, that response may not be what we expect. For example, if our application queries a service which is secured, but includes no token in the request parameters, the server will respond with a status 200, but will note in the response that a token is required or invalid. So, we should not solely rely on status codes when looking through the networking tab in our developer tools. 

Instead, we should focus on the requests made to our services by examining the query string parameters and the response from the server. To do this we select a request in the network traffic. We can spot a trend in the requests to services by the name of the request, typically they’ll include query?f=json, or the layerID and its format, such as 0?f=json, or even the name of the layer itself (if we know it). To help limit the results, we should use the Filter option to find only those requests we’re interested in, as below: 

From here, we can select a request and view its Headers tab. Again, there is a lot of important information here and it can seem overwhelming, but for now we will focus on the Query String Parameters in the Headers tab at the bottom. Based on what we know about the application and our data, we can ask ourselves: Are these parameters valid? Is this what we expect our application to be looking for?  

We can examine this piece of network traffic further and look at the response from the service that this query request receives. We can do this in two ways; 1. We can either select the Response tab in the request within our developer tools or 2. Double click on the request itself which will open a new tab, and mimic the identical request made by the application. We can explore the response in detail and learn more about what the application is receiving from this specific request. Based on what we know about the request and its query string parameters, we can ask ourselves: Is this a valid response? Does it contain the information we expect?  

If you’ve answered no to any of these questions, then it’s likely you’ve discovered all or part of the problem your clients are experiencing with your application and can investigate further. You should repeat these steps until you’ve either found the problem in one of your client's requests, or determined that all requests are working and valid. In which case, if the problems continue, you can contact support or leverage the Esri Community for more assistance. 

Conclusion:  

This was a light introduction to your browser’s dev tools and only scratches the surface of what is possible within these tools. Knowing its capabilities and how best to sift through its immense amount of information is going to become a staple in your debugging process. Examining the console and sifting through network traffic to find an issue can be tedious but finding the problem which resolves that issue is very rewarding. Hopefully in this blog you’ve realized the power of the dev tools and are now more confident moving forward with building more complex applications in your Web GIS!

This post was translated to French and can be viewed here.