What’s the plan to support native iOS and Android (and timeline)?
- What features have been isolated as necessary for helping users reduce their WUs and will be shipped within the next 3-6 months and others that will be shipped before the 18 month deadline for all plans to be on the new pricing structure?
It was evident from the outset that a feature for searches to be capable of requesting what fields to be returned was essential for reducing the WUs associated with searches, and this feature has yet to be released. I’m sure there have been various other features that users have come across that would be major wins in terms of reducing WUs, but I can not recall any new features being implemented since the new pricing strategy was introduced.
- With more and more AI systems put together that rely on APIs, and the continual strain put on the servers of OpenAI due to high demand, and the result being, often enough, errors in connecting to remote servers, does Bubble have an intention of adding the feature to the backend workflows for ‘Workflow Error Trigger’?
Personally I’ve been working with some AI APIs that won’t necessarily ‘time out’, so the concept of the extended timeout put in place recently for API calls is not of concern, it is more that these AI APIs just are being rate limited by OpenAI and just result in failed connections. When running these API calls in backend workflows, when a workflow error occurs in the backend, there is currently no way to have that trigger another workflow action so as to allow a developer to create a system to mitigate for those types of workflow errors in the same fashion that we could on pages since workflows on pages do have the workflow error trigger available.
When a workflow error occurs on the backend now, it just terminates the workflow, so a recursive workflow will just end with no ability for the developer to even simply send themselves an email to alert them to the fact that the recursive backend workflow has stopped and needs to be restarted, or more conveniently setup other workflows to automatically start it back up.
@allenyang I have a question!
When we moved to a dedicated plan, we gained the ability to control when we update our app.
In the event that updating our dedicated server’s Bubble engine goes poorly, I know we can contact support for them to manually roll that back for us if needed.
So here’s my question:
It was mentioned in passing by support that there might be a future update that would allow us (on dedicated) to roll back Bubble updates ourselves if we needed to, which would be wonderful and reduce the support team’s need to be involved in every case, which I think is a win-win. Any progress on that?
Secondary question:
How do you see the process of issuing software updates for the main cluster evolving over time? Adding the scheduled release tier was a great step in the right direction for creating stability for production apps. There’s been a lot of dialogue from the Bubble leadership team about continuing to strive toward stability and transparency while still continuing to innovate - how on earth do you plan to do that?
I would like to know when you’re going to improve the developer experience on some of the weakest UI elements:
- Group focus: enable dynamic positioning and considerably improve nested group focus
- Links, Buttons, and Inputs: enable the canvas placeholder
- Dropdown & Date/Time picker: allow way more customization
I have two questions to add:
-
If you had to put a number (percentage) on it, how far would you say you have come in addressing the technical debt from the early Bubble days and do you have any tips for identifying and dealing with technical debt in our own apps - what are some of the red flags etc?
-
Do you think we will ever see a day when it is impossible for a live standard (non-dedicated) bubble app to get broken by a platform update without the developer’s direct input? Put another way, will we ever get full control over when updates are applied to our live apps and if so, how close would you say we are to that day?
Thanks.
Not in the near future:
Finally, to the point about opting out of automatic updates on shared clusters, this is something we would love to provide, but because of the nature of shared servers, it’s a big technical investment that requires substantial changes to how we generate, package, and host applications. We are working in this direction but it’s far enough off I can’t give an ETA.
[source]
I 2nd this and expand with the ability to do regression testing AND load testing. The latter is particularly interesting to me as I’m concerned with Bubble performance under increasing load (as well as CWV).
-
Any plans to publish a roadmap for future updates?
-
Any plans for mobile native features?
There have been several replies concerning Bubble performance. I’m very interested in this too, as any Bubble site I check with Lighthouse does poorly on core web vitals performance metric. This is a big concern for me, as I 'm looking for a nocode platform to develop a commercial app where good performance (CWV) and SEO are very important. Both for website and/or PWA delivery.
Are there plans to give developers the ability to split rendering across server and client. For example… instead of rendering being primarily client-side, move more to a hybrid model where the HTML is rendered server-side and hydration is client-side. For starters, it could be a page option. Years ago we built a dynamic WCMS which allowed our clients to prerender and cache static/pseudo-static pages to improve performance. We stored these pages as .htm files so they could be “cached”. If a record, like a blog post, was updated the related record in the cache would be marked dirty so the next page request would update it. Some pages, like lists of records (things) would always be dynamic. This strategy not only produced big performance improvements, it also greatly reduced the load on the server. It would be great to have a similar capability in Bubble.
Hi @allenyang ,
What’s the plan about native mobile apps?
What is your commitment to accessibility and ensuring bubble apps can be fully WCAG compliant?