What it’s like to build in Bubble with Xano as the backend

There’s a lot of talk about alternate tools and using different backends with Bubble right now. And understandably so.

As a way of helping people understand how it would actually work to build with a separate backend, I created this video building a simple todo app using Xano as the backend and Bubble as the front end only.

Hope it’s helpful!


Hey Eli,

I have a question,
We have a huge DB, and we are using API connector right now, when we add/delete a row the data is not refreshed, even if we use the “Diplay list” in the WF - for now we refresh the page every time
My question is if we use your plugin, will we be able to solve this issue? or We would need to refresh the page even then?


1 Like

Hey @hafizaliimrankhan, it won’t refresh automatically but the plugin comes with an action to refresh the query. So if you were to add a row, there’s an event that fires when that action is complete and you can drop the refresh action inside that event workflow to refresh the rg. I go through this setup towards the end of the video.

Short answer, no page reload needed :slight_smile:

1 Like

thanks for sharing

Thanks for sharing @eli .

Mind if I ask about the impacts on your workload usage? Has it made a significant impact managing the backend externally?

@AndyP I haven’t made any changes to apps of any consequence at this point but in general, using the plugin, it’s all happening in the browser so has very little cost as far as workload usage.

Suggestion : Add a “Date” header in the api connector… On your workflow set that header to current date/time’ extract timestamp…

When you use the api connector, bubble caches your api call and won’t update new data… Unless you set a custom parameter like this one (date) that changes every time.


Can just be any parameter doesn’t have to be in the header, @future. But yeah you gotta cache bust your API calls (except when it makes sense not to).

We tested this a while back and it appears that Cloudflare caches the API results for a minimum of one minute, even when a custom header is included. While the RG may refresh, the cached data remains unchanged.

You can reproduce this behavior by performing a GET request to an API. Then, modify the data on the opposite end between two subsequent calls. You will observe that the modification does not get reflected on Bubbles’ side in under a minute or so.

I’m not entirely certain whether this issue still persists today, but it was roughly two months ago.

@Future: Just getting back to your comment.

Actually it worked pretty nice for us,

  1. we had a reusable element so we used yes/no states as a trigger
  2. To refresh the data and we used “Display List” when the state is yes and to keep it optimised we kept a second pause and then setting the state back to no.

Thanks Man! Great.


Thanks for the comment.
It worked for us! Maybe the new Bubble version updated it.

1 Like

Good to know, do you mind recording a video demonstrating the functionality?

@nocodeventure Here’s a walkthrough I did a while back on setting up this functionality through the API connector that worked fine. I wonder if the API you were using was possibly caching the data on its end?


Hello @eli ,

Thanks to you for this pluggin!

I have a set of POST request to send to Xano from bubble. However I send these requests (many) directly via the backend of bubble (need to loop)

As your pluggin is made to execute actions via the browser without the connector api, it is obvious that it does not work on the bubble backend.

Would you have a workaround for this? Or is it impossible?

Thanks !

I would save the authToken to the ‘current user’, setup privacy rule only visible if current user is this user, even if you aren’t actually using user’s in Bubble. On the back end then use the API connector and pass the authToken from the current user as a header authorization: Bearer {{authToken}}