Building telemetry to find bugs using Xano
Learn where your users are facing problems.
Building out effective telemetry collection - allowing you to track your users’ experience with the product - is critical to making it successful over the long run. Especially in the early days, detecting errors encountered by your users is the highest priority in this respect.
When building an app quickly, you no doubt will unintentionally introduce bugs into your code. That’s just a fact a of life. But how quickly you identify and resolve these bugs, however, is critical to your product’s - and business’ - success.
Isn’t all of this information already contained in the “Request History” for every Xano API, you might ask? Yes, it is, but as of this writing, there is no way to collect this information in a centralized location or get any sort of notification when a customer hits an error. Thus, I thought it made sense to build out the functionality myself.
A few notes before proceeding:
I recommend only implementing this functionality for errors triggered by the front end. That is because if you somehow designed it on the back end, then it’s possible that an API gets bombarded with calls that trigger errors in an automated manner, which will fill up your database, potentially cause performance issues, and make it difficult to identify the source of the problem. If you only are tracking manual errors that result from mouse clicks, you’ll be much more discerning in what you capture.
While I conceived of this idea independently, during my research on the topic I also identified this post - which is specific to Bubble - that covers a very similar technique.
Two options for capturing error data
Capturing all unhandled errors
You should probably have something like this in place for any application, as just getting a browser prompt in response to an error (which is Bubble’s default behavior) can confuse your users.
On a related note, you’ll also want to minimize the amount of information you display in case of an error to prevent an attacker from determining the structure of your application and database. Xano preconditions provide an effective way to customize the response sent back under certain conditions.
The only drawback to this more broad-brush approach is that I have not found a way to capture the response code (400, 500, etc.) from the error. This isn’t a huge deal but will make it harder to sort and filter the information in your feedback database.
Finally, this technique works most easily on a single page application (SPA), but you could conceivably add the same workflow to address when “an unhandled error occurs” to every page if you would like.
For a specific API call
If you want to implement specific logic in response to an error triggered as part of a specific API call (back end) or worfklow (front end), then this is the way to go.
Capture the error
In order to capture the API error, you’ll need to make sure that it gets grabbed from the API. In Bubble, you’ll need to check this box on the API connector plug-in:
Make sure that, once you initialize the API call, you get the following fields back from Xano (in addition to the normal ones containing the desired data). This information will allow you to run a custom event to take action when there is an API call error.
I built a custom event in Bubble to do this. Their documentation is not very clear, but this is how you create it:
You’ll want to set up this event to capture the following parameters from the API call to Xano:
error status_code | type: number
error status_message | type: text
error body | type: text
returned_an_error | type: yes / no
Once you have a way to capture the parameters from an error, you’ll need to kick off the workflow conditionally if the API response returned_an_error is yes (aka true).
This is what it looks like in Bubble:
Now that you have captured the correct information on the front end, you can build out a workflow that sends it to your back end.
Before proceeding, I would recommend that you build out a feedback system like the one I developed here. You can layer in the bug-catching telemetry on top of it in a way that gives you quick way to sort through the feedback (and errors) experienced by your users over time.
Having already built out the feedback APIs, I simply added a nullable column to the feedback table called error_code, of type integer. If it is filled, then you know the given row an error entry generated automatically by your front end. If not, you know it a user manually sent you feedback from within the app.
Additionally, you may want to consider adding if / then logic to your feedback POST request that allows you to not send emails if anyone from your domain triggers the error (or does so in a non-production or live environment). This will prevent you from being inundated with notifications or emails during testing.
Finally, as I mentioned in the post on creating feedback functionality, you’ll want to send the current URL the user is viewing as part of the call.
Reinitialize the POST API call on your front end if necessary, and the go back to your workflow.
Note: if you need to reinitialize and hadn’t already been capturing the API data, this may break your existing workflows, groups, and repeating groups. Your desired data will now be in the body of the API response.
Additional note: this custom event can only fire after a “pure” API call in Bubble, i.e. not after a displaying data in a group or a list in a repeating group.
Finally, plug in the appropriate parameters captured from your custom workflow and then set up the API call so that it pushes the information to Xano.
So now you have a reusable API call that you add as the last step of all of your API calls to collect errors from users interacting with your front end!