Pray for optimized JIT module loading to make it into ES6 standards?
1 Like
Well said, i am still not convinced that bubble can handle such a large application with 100k users
1 Like
@abc You must ask the support via email about this matter, and yes do share the reply with us
What do you base this on?
For clarity, these were not SCALE issues, but data admin at scale.
Getting half a million rows in there via recursive workflows running against APIS ā¦ simples*
Deleting those rows ā¦ remarkably tough.
*well ā¦ with hindsight.
3 Likes
I suspect you will just uncover a whole bunch of different issues.
There is a trend towards moving things to Xano etc ā¦ but this worries me. Not because it isnāt a good solution for SOME, but because without knowing the issues in Bubble in the first place, you donāt know what it is you are apparently improving.
6 Likes
Perfectly stated, @NigelG. Iām a huge fan of Xano but there should be a defined reason for using it instead of Bubbleās db.
To this thread in general I would say, todayās Bubble is NOT two years agoās Bubble. There has been a giant leap forward in performance and functionality. 
6 Likes
Can you elaborate?
I am newbie so I think that itās great to host a big database in Zano or any DBAAS to reduce load on bubble, query the results there and get the data via API. please correct me if I am wrong.
In my, relatively recent, experience with Bubble I think it is well tuned for itās primary use cases: user management, conditional navigation, and to a lesser extent user data entry. Up to latencies in loading Javascript libraries, Bubble appears to be tuned to operate just barely faster than user interaction and attention span. And that is a solid and entirely defensible design choice for a front-end system.
Now the tuning for data processing and management at scale is an entirely different beast, and the two different optimizations often can not be reconciled with each other. Long story short, front end at scale means moving relatively small amounts of data between a central service and thousands of clients, where as data processing means streaming and modifying large amounts of data between a small number of clients.
To put it another way: if you want to be able to host up QR codes certifying COVID vaccinations for a million people, Iām confident Bubble can scale. If you want to have 10000 users simultaneously editing and rendering each othersā LaTeX documents, with full version control, well things would get dicey for a lot of different platforms, including Bubble. For example consider reading through the Twitter architecture.
2 Likes
Thanks @NigelG. When you say āI suspect you will just uncover a whole bunch of different issues.ā Could you take a stab at specifics or at least the areas you would have the most concern about? Maybe there are some things I could test/redesign early on and avoid some pitfalls.
2 Likes
Off the top of my head Identity Management between the two systems is an immediate complexity you will encounter. Synchronizing user identity and access between databases is an entire IT industry all to itselfā¦go ask an enterprise security architect.
I use Xano for a few projects, and I would say that the 3 main things you sacrifice when using Xano are:
1.- Development speed: bubble is easier when it comes to create logic, everything is optimized around Bubble internal tools and makes it easy for you to bring external data to your app. But what you donāt see is that Bubble generates all the main endpoints for you (create, read, delete and edit records) and with simple conditionals you can control your workflows. Xano also autogenerates endpoints, but you will have to create the logic in the endpoint itself or use other auxiliar endpoints to put the conditionals in Bubble (which I do not always recommend). Changing the schema is also painful, if you change your data structure or API response, it might require some significant effort to reconnect it to the Front end.
- Simplicity as you require some specific knowledge: like how to format/transform timestamps/dates or how to manipulate lists and objects, Bubble simplified the data manipulation to a readable and easy to use UI. Xano on the other hand, needs you to understand some ācode structureā, like loops, conditionals, Objects, arrays, JSON, etc. Is not hard, but is something you have to learn.
3.- Itās easy to break: recently Xano created a version control feature, but is far from being optimal. When versioning your endpoints you will have to always create backups and create your own āstagingā environment. I always have at least 3 duplicated endpoints, one for the dev version, one for testing and another for the live version. Keeping them sync is not simple.
4.- (Bonus)You will loose Websocket: this one would be relevant depending of the use case, but for sure is something that many people would miss. Websocket is, basically, what updates the data in the front end when it has been manipulated by someone else in another device, by a webhook or a scheduled task in the backend. So if you update records in Xano, it wonāt be reflected in the front end until the user reloads the page or triggers somehow the API call again.
Now what you would win?:
1.- Speed and more data filtering capabilities: Xano is much faster than Bubbleās backend, but I would say that this improvement is only needed when you are doing some heavy queries (like displaying hundreds/thousands of data things connected between many tables) or pre-processing the data before returning it. Using addons (similar to graphql) you can pull data from other tables in a single call and only fetch the columns you need of each table.
2.- More data processing capabilities: this is the major reason of why I use Xano, performance is nice, but itās not needed in most cases. A big difference from bubble, is that you can manipulate your data at will. For instance, when I fetch a listing of locations I can return the distance of all the locations to a specific point (or listing of points) using simple loops and built in calculator features, but to do so in Bubble is more complicated. Also, you can merge data from different tables/data sources in one single call, this is powerful. For example, I have an app that has 2 different data providers (I do external API calls), you have to do magic to merge both data sources in one repeating group by just using Bubble and the API connector and even then you will have troubles further sorting and editing the data, well Xano allows you to build your own response/schema and add as much details as you want, you can even sort the resulting array using your own structure.
3.- Other desirable features that bubble doesnāt provide: Iām not going to get into details, but there are a lot of small features you wish bubble had, that makes your life simpler. That being said, this is truth in for both solutions, in Xano I also miss other features that bubble has (like websocket as I mentioned).
When to use Xano?
In my experience, you should use it only when it becomes painful to solve stuff in Bubble, which are odd cases. If you need more data manipulation capabilities, or your queries are just too heavy and you have huge load times, then I would consider external solutions, but I prefer to keep everything in Bubble if it is possible because it makes my life simpler, when there are stuff that bubble itself cannot do or it is too slow, I just turn to Xano because itās a need and not something nice to have.
If you are planning to have Xano as a backend in the future, take into consideration that you canāt export users from Bubble, so either you force a reset pw in the future or you mirror your user table in Xano.
Hope it helps!
16 Likes
I wonder which app is itā¦and yeahā¦who built it!
1 Like
Hello. Iām developing a (https://geekle.us app). This app now has >100,000 users. Our main load is events for which up to 2000 users buy tickets. Our plan is professional + 3 units.
22 Likes
Thanks for sharing this amazing app, how you decide when buy more units? The app rich out the capacity and your app stop working?
We buy additional units.
We buy additional units. Sometimes there are enough test units. Because We have events twice a month.
3 Likes
At around 11:55AM - 12:15 PM app got 2k active users and reached about 90% CPU and 70 % capacity with about 2.5k workflows and that also in professional plan + 3 units.
I think it should be using less capacity and resources.
I donāt know the app complexity but still i thought production plan should give more just more.
2 Likes
It all depends what you have on page.
We have a lot of WFs related to analytics on our page. Therefore, user transitions between pages are very busy.
2 Likes