API call performance impact

How much do an API call that will not store data (only display on the user browser) affect the app performance?
Is it better to make this call every time with an API or to store this data?

Thanks :upside_down_face:


I connect to Firebase through the API and the speed is lightning fast, faster than it takes to load Bubble data.

I don’t know jow other providers work.


1 Like

Will check this! Thanks

That piqued my interest. Could a no-coder easily build a Firebase database? Is it as easy as the website says it is? What’s hard about it? What do you like most.

(sorry, couldn’t resist the game of 20 questions.)


Interested in the answer too @mangooly

Following too @mangooly

I’ve always had this question, which is faster pulling data from Bubble database or form an API call?

@LinuxUser @Bubble

I am especially curious to know if a call that does not enter the Bubble database and has only a display purpose has an impact on performance

Note that there is some small amount of overhead in calls made through the API Connector, regardless of what you’re doing with the data (i.e., displaying the data in the page, sending to a custom state, etc.) versus the performance you might see in a natively coded JavaScript app.

The performance of the API Connector is still the same as you can see in this older video of mine (which is not specifically about the API Connector, but about performance of server-side actions with respect to other FaaS services serving up an API): Will Server-Side Actions Ever be Viable? They are Ludicrously Slow to Instantiate

In the video I link to above: The “webtask” called via the API Connector spins up and provides its return value in a couple milliseconds, but as you can see from the blue bar, Bubble takes a bit of time to either fire off the call or to process/publish the results of the call (probably a bit of time on both ends of the transaction).

But more to the original question, there’s not any “performance impact” to API calls. (Making an API call via the API Connector either as data or as a workflow action simply takes as long as it takes to fetch the data.)

As to the question of whether using Firebase as an object storage and fetching similar-sized arrays of requested data would be any faster than Bubble’s native database, the Magic 8-Ball says, “reply hazy, try for yourself”.

Personally, I suspect (based on a LOT of experience with Bubble internals) you’d find:

  1. Fetching a single item from Firebase via Bubble’s API Connector would be markedly slower than native fetching of a single, identical object. (Simply due to API Connector overhead.)

  2. Fetching a very large array of identical objects from the native Bubble database and from Firebase (by very large I mean a sufficiently large array such that the API Connector overhead of some-small-number-of-seconds become noise), you’ll find that… the results would be different. :wink: But it’s hard to say which one would be faster and why.

(I suppose I could test this, and I might out of curiosity, but it’s kind of one of those “why should I?” things. I’d much prefer that someone from Bubble address these kinds of suppositions. :woman_shrugging:)


In my example I pull data from Bubble and from Firebase API using GET on the same page. As a user when I load the page and to my surprise the data from Firebase loaded half a second to one second faster than the Bubble data.

1 Like

I am a no coder and I have learned the basics to POST, GET and DELETE data. I think its pretty easy for a no coder to learn. It just takes practice and more practice. There is no coding involved.

1 Like

following this also

This topic was automatically closed after 70 days. New replies are no longer allowed.