Thats actually not bad for the personal plan, are there any courses or tutorials as to how to optimize it? My apps will probably have more workflows runs though.
Sure thing, its a CRUD apps that generate a PDF or a simple web page for the users. Kind of like these Resume builders, but for a different niche.
Not that I’m aware of. There are some nice posts written by josh on these forums talking about performance. The rest is basically DRY, use custom states where appropriate to avoid unneeded calls to the DB, use styles as much as possible and avoid using single element styling, don’t abuse conditionals in workflows and/or elements and use wisely the terminate workflow if you don’t need anymore to keep running. I also have some JS paired with elements naming convention that allows me to take DRY a bit further.
One last question, have you ever used this:
for scheduling API workflows?
Not for production ready apps. I’ve played with them here and there, but nothing serious…yet.
I specially like this one: A fair and honest chat about Performance.
Are you asking JonL in particular? I would guess that Zapier is widely used. I use it.
Thanks for the link.
It was an open question, of course
This community is really awesome BTW.
small correction - this is not our portfolio (Except the templates section) but a collection of apps built on Bubble by the community
Thanks for the clarification!
In the personal plan I’ve maxed out apps at around 100 workflows/minute in stress tests.
Being the workflows a mix of client actions and one database write action.
@JonL any experience on how the performance improves when going to a professional plan?
In my use case it doubled. So around 200 simple workflows a minute.
I never tried with scheduled workflows though.
When you say workflows, you mean each group of workflows (so 100/200 groups) or 100/200 individual workflows?
this is quite depressing to be honest
So basically if i have more than 5-7 users logged in and doing simple CRUD workflows, thats its.
That is why Bubble is great but not a panacea.
When I realised the limitations of Bubble I had to change how I selected what projects to build in Bubble.
So in the end it’s not the tool, but for what and how you use it.
Imagine you buy the best pickaxe in the world and you start chopping a sequoia. You would get depressed quite soon. Even with the best pickaxe of the world. You either change to a regular axe or start bashing rocks.
So if you want to build the next Twitter or real-time social network with millions of concurrent users you better go and buy an axe. Or do what I do…think about looking for rocks instead of trees. After all…you’ve got the best pickaxe in the world
Sure thing, i agree with you 100%.
I’m only planning using bubble for CRUD apps, but 100 to 200 workflows a minute is not stable even for a very small CRUD app from my point of view.
I’m doing anything to reduce the amount of workflows, even shifting some of the product features to other platforms (the billing and user management system).
I guess on the long run im going to use rails.
I would say that CRUD apps for SAAS with high paying ticket users is where money is. This the general rule for web apps, but specially for Bubble. Think about professionals that need CRUD systems. Because for each paying user you can afford to buy capacity.
As you mentioned, if you work with Schedule API all the time, and execute in the background all the process you can without slowing down user experience, it will be faster, even with 1000 or 10,000 concurrent users (still in beta for me) I accomplish now workflows that was taking 20 sec in 2. Stable it is. Based on NodeJS and PostGres DB technologies.
Agreed. NodeJS was built with that in mind among others features.