Iāve implemented an interface for others in the form of plugins, so I have some experience to share
Itās usually fine after itās implemented. Itās not cheap or quick to do a full implementation. Not always a full implementation is needed, it can be partial and that makes it less costly in time and money.
Also, in terms of how it feels, when the interface, and by interface I mean workflow actions created in the plugin that performs the Search, Create, Read, Update and Delete operations, is through server side actions they have an unwanted delay of 2 to 3 seconds, whereas when we make them client side, they get ultra fast, instant to the human feel, they take from 200 to 350ms, which would be 0.2 to 0.3 seconds for the ones not used to work with web requests closely
And to use the interface firing the requests from the browser instead of involving Bubbleās server twice as a middleman, once to fire the request and again to receive the response then send to the browser (which is what adds the 3 seconds delay), itās needed to use JWT or SSO to auth instead of just secrets held in Bubbleās server.
I have an Bubble app in closed beta right now that is connected to a MySQL database on Amazon AWS/RDS. For my use case, itās been great. The database currently has 10ās of thousands of rows, so not very big at the moment but big enough Iām confident in the architectureās capabilities. The Bubble SQL Connector has worked great, itās fast, and the system is scalable.
I have experience using Firebase realtime database with the API connector and the speed is lightning fast. It loads faster than the Bubble database. Give it a go and try it for your self.
Web app will be on bubble, but mobile-native apps built using a different solution, most likely Adalo.
Will like them to a common backend, most likely on Firebase, though may be swayed to go AWS if I successfully get the AWS Activate credit for our startup.
Have you used the Bubble API connection before? I suggest you start there first. Look at the different videos available on Youtube. Once youāve done that and you have setup your Firebase database you just have to add the authentication key in the Bubble API connector. From there on you use the different url parameters to post, delete or get information from Firebase. I suggest you look at their documentation too for all the different parameters. Itās also important to make sure you have security measures in place on your firebase database and you donāt allow writing or reading permissions, etcā¦
Dear @mangooly,
Thanks for replying to my questions, actually I have done API Connection using a service to call google sheets API,
However, I feel like the speed was not very optimal , and there are limitations to Google Sheets Database Size. Thus I am interested in different APIs,
The problem for me with Firebase is the schema return in Data Connection -, not very friendly for āfilteringā or doing some basic calculation ,
Thats great, so you know the basics like me. I also started using google sheets but it was so slow and for privacy reasons I prefered using Realtime firebase with servers located in Europe. Unfortunately I havenāt used it for filtering or calculation. Iāve only used it for getting, putting or deleting information. I donāt know what is the best way. I imagine there are two options, filtering or calculating data directly from firebase. You would need to look at Firebase documentation. Or the other option would be to pull all the data to Bubble and then filter or calculate the data in Bubble. The first option seems the fastest so my best bet is to look at the api calls to see if and how this can be done, and then go for option B if that doesnāt work. Sorry couldnāt have offered more help.
Hi @mangooly,
Thanks for sharing , I havenāt taken enough time to read more about firebase , will search more to see if you can filter the data in the API url
Iāve worked on an app with an external database. Main issue was was filtering and having to rely on/with empty constraint. Such behavior is native using Bubbleās database, but when using external data it becomes less āeasyā.
We had to implement wildcards on the external side.
As we were talking about thousands of rows to GET, it was nOT possible to filter on Bubble side, since just downloading them wold take to much time
Sorry, I have no idea. I think Bubble can give you a better answer to that. If you could publicly put that info here once they answer your question I and other users will be very grateful.
Sorry to be coming back into this conversation months after you asked the question.
Weāre building our application on Firebase - External database, user authentication, notifications etc, and to date have not run up against any Bubble limits for writes to or reads from Firebase.
Weāre developing our own plugins to do the interacting with Firebase, but version 1 has been built executing the calls through the Bubble API Connector without any issues around volume. There is a learning curve to making it function the way you want and structuring your workflows to ensure that you donāt run up a huge Firebase bill by constantly reading and writing, but so far so good.
This is seemingly unlimited as they donāt mention api call caps. Plus, with a guarantee of a one second query time even when youāre querying over a million records it seems to be the better option in terms of data bases for large data sets.
That said, using a bubble database is so much damn easier. You donāt have to set up indexes, you donāt have to struggle to set up search filters, you simply tell bubble what you want and it pulls it out for you and it makes adding constraints/filtering/ordering so much easier.
Just to add to the discussionā¦I agree with your comments about setting up indexes and the general point that itās easier to work with the Bubble DB within your app. Dealing with matching up Bubble to the results coming from the connector can be a pain for sure. But there are some huge advantages to using an external database where Bubble falls short IMO. For example, I constantly run ad hoc queries and do other things with my external DB - for debugging, setting up test data, backing up tables, running reports, etc. Iāve found stuff like this takes forever to do in Bubble, especially when dealing with multiple tables. Itās way faster to just write the native SQL and itās very easy to do things like export the data to Excel.
Also, for both flexibility and performance reasons, I prefer to do some of the complex filtering with SQL (especially when dealing with queries across multiple tables) and then use Bubble after that for further manipulation and presentation.