Bubble.io: pros and cons
05 May 2023 -
How did I end up with Bubble.io?
As I started developing NoFaceMeeting.com, I initially turned to Ruby on Rails, a framework I had experience with but hadn’t used since Rails version 2. Since then, Rails has evolved significantly, and is now at version 7, offering an ever more robust ecosystem with up-to-date tools and wide community support.
So, I needed to take some courses.
However, my impatience led me to explore the world of no-code tools, where I discovered Bubble.io. In this blog post, I’ll discuss my experience with Bubble.io, its limitations, and its risks.
The Power of Bubble.io:
Bubble.io is an excellent choice for quickly developing a functional product, as it allows for rapid development and deployment once you’ve overcome the initial learning curve. With its great support for responsive design and object-oriented approach, I found the platform easy to use and efficient. For example, the blog section on NoFaceMeeting was developed within a few hours using Bubble.io.
Here are some pointers to the in-depth courses I followed to get myself started:
- Gregory John from Bootcamp has a great course on Udemy.
- The books on performance and on security by amliesolutions are a ‘must-read’.
- If you are still evaluating whether to go for Bubble or not, I found this 3h video really insightful.
Limitations of Bubble.io:
Despite its many advantages, I encountered a few limitations with Bubble.io.
The privilege structure (to restrict who can see/update what) is quite restrictive, complicating the implementation of access rules in certain situations. All Bubble privilege rules are defined as part of the definition of an entity (e.g. Order, Customer, Invoice…) and need to be expressed either
- from the viewpoint of the entity itself, or
- from the viewpoint of the current user.
This means you need some workaround in case you need to make the access to that entity depend on another entity.
Suppose you have a meeting entity and that meeting can have 1 or more topic entities (through the ‘has_agenda’ relationship in the diagram below). You will want to restrict access to a topic in a meeting to the attendees of that meeting. In that case, Bubble forces you to duplicate the attendees to the level of the topic.
You see where this is going when each topic consists of multiple steps and each step has multiple comments. Per comment, there can be multiple attachments. There is a cascade of updates required from meetings to topics to steps to comments to attachments, each time an attendee is added or removed from a meeting.
A better way to solve this is to define a new field on your meeting table that contains ‘a list of’ topics. As long as your 1-to-many relation is not expected to explode into several 100s or even 1000s of child entities, that can be a workaround.
However, this does not work if you have many-to-many relations: e.g. a user can belong to different teams and teams have several users. As each user can have different roles depending on the team membership, you need a membership entity that models the many-to-many. Also, in this case, team and user info need to be duplicated on the child membership entity.
Do we really want No Code?
After a few weeks of intense development, I hit a few show-stoppers. For example, to calculate when a meeting ends, I needed this simple calculation:
MeetingEndDate = MeetingStartDate + MeetingDuration
Of course, this calculation should be in ‘workdays’ and not calendar days. Moreover, if one of the participants lives in a country with a national holiday during that meeting, we will need to take that into account. As you can expect, there is no way to express that logic in a No Code way.
Automated test runs
Bubble.io has no support for automated testing tools. As a developer who appreciates the importance of testing, I found this to be a significant drawback. I ended up selecting Selenium WebDriver and developing a number of shell scripts to test out the business workflows in my app. This library saved me a few times by uncovering errors before I released it to production.
Bubble.io received a $100 million investment in 2021. On the face of it, this seems like a good thing, but I wondered why that amount is so absurdly high.
Of course, these investors want to make a profit, and I’m guessing that is one of the reasons why we’ve recently seen the introduction of new pricing plans based on your app’s server workload.
There is a big outcry in the Bubble forum about the introduction of these new pricing plans. While Bubble’s communication on this topic might have been handled better, price increases are not a problem as such. I still believe I am getting a lot of value from not having to care about hosting, release management, backup, and a lot of other sys admin tasks.
Gentle push to upsell you to a higher plan
Another indication that the investors want to see a return is the regular emails I started to receive with the subject line
Your application has reached its allocated capacity
Of course, the email kindly suggests to “.. add more capacity for better performance and to prevent your app from being rate-limited.” Oddly, I started to receive these emails even before I had any users on the application. However, to be fair, this could be related to my automated testing scripts.
Is there a platform risk?
It’s essential to be aware of the potential platform risk, such as what would happen if Bubble.io were acquired and the product terminated or for some other reason stopped working. The company has provided a transparent solution in such cases, offering to open-source the platform, allowing users to run their applications on their own Bubble server.
The Ecosystem and Add-ons
There’s a thriving ecosystem of developers and add-ons available for Bubble.io. While the add-ons developed by Bubble.io itself are well-supported and functional, the quality of third-party add-ons can be questionable, often lacking support and functionality.
What about compliance?
If you are in healthcare, Bubble is not an option for you. This is currently Bubble’s viewpoint on this: …we are not currently actively pursuing HIPAA compliance. We are instead looking more into compliance certifications that would address a wider range of use cases to start (e.g., SOC2)
In retrospect, using Bubble.io for my project allowed me to achieve results quickly but required me to find workarounds and implement additional functionality on a separate server. As I consider future projects, I’m left questioning whether I should continue using Bubble.io or return to Ruby on Rails, a technology I’m familiar with and have loved working with in the past.
If you are considering Bubble as your No Code platform, make sure to spend time and money learning about the tool. It can be a really fast way to develop an initial version of your product. Also, in case you need some internal application to manage internal processes without too many fancy or complex calculations or privilege logic, Bubble might get you something operational very fast.
If you have any questions or would like to share your experiences, feel free to reach out to me via email. Thank you for reading!