I’ve recently been doing a lot of work on a Bubble application which uses Xano as it’s backend database, with API calls and the Xano plugin to connect the two systems. It’s definitely a very powerful pairing, allowing for a lot of data processing, queries and such to all be performed off-site and the relevant data returned to Bubble, but also has its fair share of issues.

One thing I have noticed overall, however, is that the speed benefits of using this instead of Bubble’s native backend can vary wildly. In some cases, it can process data and give a response in a significantly shorter amount of time than Bubble could ever achieve, even with proper optimization. But in other cases, there appears to be no real speed benefits, and even sometimes net loss when it comes to smaller amounts of data or more simple requests.

Workload

Possibly the greatest boon from this is how much workload this takes off the Bubble side, with all data processing, calculations, queries, etc. being done in Xano. This means you will require significantly fewer WUs/month to run your application, and the cost of Xano is usually low enough that, on more complex data-structures, you’re significantly better off using a third-party database. It also makes scaling significantly easier and can even make the transition off Bubble simpler too, as there will be no need to migrate your entire database. It’s already off-site.

Also, given how Bubble handles being used as a pure front-end, receiving the data itself from Xano can be somewhat problematic. The biggest offender here appears to be using the Xano plugin to call Xano endpoints.

In this case, the Xano plugin cannot natively recognise the data being passed in (even though it’s raw JSON). This means that you need to use Bubble’s API connector to create “empty” API calls and manually enter what the response’s JSON from Xano looks like. You can then use this as the datatype for the incoming payload to successfully parse it into a form that Bubble can handle and display.

But, there lies another issue with this. If Xano ever sends a “null” value for ANY of the fields that are expected to be parsed, the plugin element will completely break and return “no data”, even if it’s received the complete JSON for everything else. Unfortunately, there doesn’t appear to be any way to “force” the plugin to accept null variables, meaning that the only options are to either not include the null data in your call, force the data entry to always have something in that field (cannot create without field being filled, for example) or to make a workaround to “parse” the null.

Unfortunately, this “workaround” won’t always work, depending on data that is being returned as a null. The general gist of this “workaround” is to make a separate API call within Xano to return just the specific item’s list.

For example, you may have a list of tickets that contain bugs on a platform, and each ticket can be assigned to a developer for resolution. Because of this, the ticket may not always have a developer attached to the ticket, resulting in a “null” entry. This can then be the cause of a data source break.

The workaround here is to make the call for the list of tickets without the developer attached to it, then make an individual call to a new API “ticket_developers” that gets the single/list of developers attached to the ticket. The reasoning behind this is that, if there are no developers on this ticket, it will return a null and the data source will break, but because there is no other data being expected with this call, a break doesn’t actually impact the functionality of the site what-so-ever.

This does then raise its own suite of issues, including increased complexity of the application and the inability to use this specific data field at the top-level for the general list display, as well as making the application heavier on API calls, as it now has to make one every time a list item is opened. But at current, it seems like the only way to handle a null-returning list with a direct Bubble connection.