Hi all,
This is our June community update! Read last month’s update here.
May was a pretty heads-down, productive month for us; we made a lot of headway on various projects and released quite a few things, although that was marred by some rollout-related incidents, discussed more below. We also continued to expand the team at a steady rate. New hires include:
- Rob, Michael, and Abel, joining as engineers
- Leon, joining as an engineering intern for the summer
- Christine, joining as a designer
If you’d like to join us, our open roles can be found here. We always value previous Bubble experience when hiring, particularly for our Technical Product Support Specialist role.
Changes we made this month
We continue to prepare for making our new responsive engine the default for new apps: this month we took the updated plugin editor out of closed alpha so that all our plugin builders can start porting elements to the new engine. For most plugins, this should not be much work, so we strongly urge plugin developers to do this. As a reminder, we would also like to get as many of our templates on the new engine as possible.
Our performance optimization for pages with lots of invisible elements also went live as an experimental feature. We are monitoring for potential bugs and will release it to everyone once we are confident it is stable. Early testers are reporting very significant speed improvements to their pages!
We also launched a number of long-requested features:
- Multiple parameters on custom events which enables using custom events instead of API workflows in many situations where custom events are more appropriate
- The ability to trigger API workflows via a GET http request instead of a POST request, which allows certain integrations that were previously blocked
- Padding controls for a number of visual elements that were previously missing this setting
- Dropdowns with cross-browser compatible styling options
In addition to those features, we are experimenting with in-editor educational resources: new accounts may see video popups on the Data tab and Option Sets tabs explaining those features in more depth.
We also published a number of blog posts you may be interested in:
- Petter Amlie’s Tips to Maximize Your Bubble App’s Performance
- How to Build a Cash-back app
- How To Build an NFT marketplace/opensea clone
- Community spotlights on Bubblers Building in Public: Neil Pierce, Jean Baptiste, Lee Hills
As well as news coverage of Bubble:
- PC Mag reviews Bubble 4.0/5.0: “The vast majority of people, from personal hobbyists to small business owners, aren’t hardcore professional software engineers. They should still have a way to develop all sorts of sophisticated web apps. Fortunately, Bubble is an excellent and capable platform for that audience.”
- Fast Company on no-code and Bubble: A computer scientist explains how nonprogrammers are building more of the world’s software
- Inc: Josh explains company values for founders
Finally, one other thing to mention is that we have been dealing with an increasing number of bad actors using Bubble to send spam or host phishing or other fraudulent content, and have been making some changes to shut these activities down, including mandatory verification of Bubble user emails and additional free plan limitations. We may make additional changes over the next month or two: we will do our best to communicate transparently with the community and limit any impact they have on legitimate Bubble use cases.
This month in numbers
-
New conversations via bug reports or support@bubble.io: 9,698 (up 11.3%).
-
Average first response time to messages: 2h 15m during business hours (up 69.2%)
-
Average response time to messages: 2h 26m during business hours (up 50.5%)
-
Open tickets being investigated by the engineering team: 63 (down from 65)
-
Of those, tickets that have been open longer than 7 days: 24 (down from 25)
Things on our minds
As mentioned above, we had several rollout-related issues recently, primarily related to the multiple parameters on custom events project. While we are glad that project is out the door, the negative impact to our users from the issues was very high: we broke apps in production, some for an extended period of time, and some on the Scheduled cluster. We just completed an internal retrospective on the project and rollout issues to understand what went wrong and how to prevent it in the future. The key issues we identified were:
-
We made a non-backwards-compatible change to the way we store applications. This was the main reason the user-facing impact was as severe as it was: we were not able to immediately revert the change once we realized there was a problem because apps had already been altered, so we were forced to solve forward to fix the problem which was a significantly longer process. It also meant that transferring apps between the Immediate cluster (which had the new code) and the Scheduled cluster (which had the old code) was not safe.
-
Our testing process for this feature was focused on the custom events feature itself, but the changes touched code that was shared with other features (the Draggable UI plugin, Schedule API Workflow on a List, Set/Cancel Recurring Events, and On Error Events). Our test plan did not recognize that those features could be impacted, and we did not manually test them. On audit, we discovered that the automated tests we have that were supposed to prevent those features from breaking were either placeholders or only covered a subset of functionality.
-
During code review for the feature, the senior engineers reviewing the code felt unsure about approving the pull request but could not vocalize any specific concerns. This led to to the pull request being approved and deployed despite those reservations.
-
We released the feature shortly before a long weekend, with lower team staffing levels, and our response time to user bug reports was longer than usual. Since we do maintain weekend coverage, we are conducting a separate retro on why there was a delay in the issues getting escalated.
We are still discussing action items coming out of the retro, but likely next steps include:
-
Making sure that future changes to the way we store applications are done in a backwards-compatible way, so that it is safe to revert code. Also, we may make heavier use of the experimental feature flag so that the likelihood of needing to revert a feature that users have already begun to incorporate into their applications is lower.
-
Writing tests to cover all the gaps in our automated test coverage that we discovered (already in progress)
-
Working with our outsourced test provider to build integration test cases based on more real-world examples to better capture unknown unknowns
-
Modify our project planning process going forward to ensure that the test plan includes checking for other features that could be impacted by the change
-
When reviewing code, setting expectations around reviewers having the right to ask for more time or flag things as potentially risky even without specific concerns to encourage hitting the brakes on changes that we feel uneasy about
We know issues like this can be incredibly disruptive to businesses built on top of us, and we are very sorry for the negative impact. We are committed to learning and improving from mistakes and evolving our processes and technology to make them rarer and rarer.
What we’re currently working on
As discussed above, we are preparing our new responsive engine for a full rollout; at this point, the majority of the work is coordinating with our ecosystem to get things ready, as well as porting over plugins that we built in-house.
Following up on our latest post about pricing, we are continuing to do technical investigation work on capacity and auto-scaling. As mentioned in that post, we intend to do further rounds of community feedback once we have completed the technical investigation work, and do not anticipate releasing anything disruptive that would jeopardize anyone’s ability to build on Bubble.
Other ongoing workstreams:
-
We finished collecting feedback on our mockups of our improved version control user interface. Feedback was very positive, and we are planning to start engineering work mid-June.
-
We are nearing launch for the next phase of work for generating HTML and CSS upfront instead of on the fly. This will be an intermediary release that will still involve on-the-fly generation of the HTML, but will lead to significant performance improvements and pave the way for future work.
-
We are close to launch for performance optimizations to make bulk data manipulation via backend workflows faster.
-
For the overhaul of our network architecture and infrastructure, we have built out draft gameplan for the first piece of work, and hope to staff engineers against it in June.
-
In order to increase our overall reliability, we are working on the way our alerting and observability systems work, so that we can be more proactive about tackling impending problems
-
We are actively working on our project to improve how easy and fast it is to build beautiful apps on Bubble. The project involves improvements to managing colors and fonts across the app, and a replacement of our under-used element templates feature with a more mature component system. This workstream led to the release mentioned above of padding support for more elements.
-
Our push to migrate code of CoffeeScript continues; we are now down to 36.9% CoffeeScript in our main codebase.
Thank you so much to everyone who participates in the Bubble community!
Josh and Emmanuel
