Hey Bubble Makers! We’re already more than 300 readers and I’m seeing a lot of new faces. I’m grateful. There’s really no better feeling than helping and learning at the same time.
If you’ve been following the newsletter for a bit of time, you will have already noticed that I enjoy experimenting. It allows me to see which newsletter format both you and I prefer.
That’s why this week’s issue of Bubble Makers is more technical and longer than the previous ones. I wanted to go deep down on some topics.
That said, some things never change. As usual, it includes:
One section for Bubble beginners
One section for more experienced Bubble makers
One cool app built with Bubble
One tweet related to Bubble that I found inspiring and helpful.
Feel free to skip to the section you think you’ll enjoy the most!
The Beginners Bubble
When you’re building your app and imagining how it’ll look like, you picture a full database from the beginning.
Building a job board? You might be imagining hundreds of different jobs to pick from.
A CRM? You’ll probably be wondering if your plans should start from 100 or 1000 users.
A marketplace? In your mind, it already includes hundreds of products divided into categories. No reason to have that Search page if there are only 10 products.
However, your app won’t have any products/jobs/users at first, so you’ll find yourself looking at a blank screen unless you create the data yourself.
Or… you generate it with a tool and then upload it to Bubble. Definitely better.
Today’s tip is to use Mockaroo, a free random data generator that lets you generate up to 1,000 rows of realistic test data in CSV format. It allows you to leave some blank fields to simulate a real dataset (maybe 20% of your users won’t have a profile picture or 30% won’t create a task in their to-do list).
Data can be of various types:
Location (e.g. City, Country, Latitude and Longitude, Street Address, Time Zone)
Commerce (e.g. Credit Card Number and Type, Currency, IBAN, Bitcoin Address)
Personal (e.g. Avatar, Name and Surname, Gender, Job Title, Language, Race)
Company (e.g. Company Name, Marketing Slogan, CEO (just pick a normal name)
Nature (e.g. Animal and plant names (common and scientific))
A lot more things like cars, movies, products…
Once you have your CSV file, you’ll be able to upload it to the Bubble app. There is, however, one bad thing: uploading a CSV file to the database is only possible in paid plans. So, it’s something that will make sense only for certain projects.
The Makers Bubble
This week, I want to talk about one of the most common questions that arise when building with Bubble.
Can Bubble handle my [[insert huge number]] rows of data?
The answer is yes. There is no actual limitation on the number of rows that a Bubble app can handle.
However, there are some nuances. It’ll work, but it’s hard to tell if the performance will be as good as you want it to be. Also, you’ll need to ask yourself these questions:
How will this data appear in my Bubble app? Do I need to upload it?
Is the data clean?
Will the data be updated only from the Bubble app or will it be updated externally too?
If it needs to be updated externally, how often will it be updated?
If you plan to handle a big amount of data in your Bubble app, you will likely have thought of uploading a CSV file. A few points based on my experience:
Estimate an upload time of 1,000 rows per minute. So, if you have 500,000 rows, estimate 500 minutes = 8 hours.
Make sure your data is formatted before you upload it. Bubble is picky! For example, numbers can’t include commas or dots and if a column has a number format, no data point can be a text value. You don’t want to run into errors like this one, where you upload 300,000 rows and get an error in row 161,000 😅
If you need to delete rows, keep in mind that will take time too.
If you need to upload big chunks of data, I highly recommend the 1t - CSV Uploader plugin developed by Eli. I have tried it myself and the process is 2-3 times faster. Also, this plugin allows app users to update CSV data to the database if needed. This is the preview page that Eli prepared to help you learn how to use it.
Now, as I stated before, you will also need to ask yourself:
Do I need to pull data from external data sources?
How often will I need to pull data?
If you need to refresh your data frequently, you might need another solution. Here is where I want to talk about what my friends Kevin and Kieran have done for their upcoming project, Community Copilot.
They are building a tool for Slack and Circle communities, to help them get better analytics and increase the engagement of every member (watch this Loom video if you’re interested in seeing the current state).
As you can imagine, a SaaS like this one is really data-intensive. Just visualize a community with 1000 members, each one with 150 data points (i.e. their personal data, their engagements, their comments...). That would be 150,000 rows of data.
Now, imagine connecting 20 communities. Or 100. Millions of rows!
Kevin and Kieran have chosen to combine Bubble with an external backend. They’re using hasura.io, combining a PostgreSQL database and a GraphQL API. This might sound a little daunting, but believe it or not, they haven’t written a single line of code!
Are you saying I can create my own database and connect it to Bubble?
Precisely that. If you have the time and are curious about how you can create a PostgreSQL database “from scratch”, you can watch this video. It will guide you through everything you need to know to set it up.
However, you don’t need to create the database yourself.
There are no-code / low-code tools that will do it for you. You will need to understand what a primary key is and how your tables should relate between one another, but it will be much faster.
If you choose to use Hasura, you can follow this tutorial to set it up. They will help you populate your database and create the GraphQL API for you. You can then use it as it is or you can add custom logic through code and/or SQL.
Another great no-code backend you can use if you want to use an external database is Xano. I find it a bit easier to use than Hasura and they have a section specifically for no-code makers to help you learn the basics.
They also provide you with a PostgreSQL database, this time combined with a REST API to access it. From there, the possibilities are endless.
I need to stop here to make a clarification. This is easy to set up but it is far from being simple. Don’t be discouraged if you don’t understand everything, because it is completely normal, especially at the beginning.
My advice is to be patient, watch Youtube videos for beginners and ask a LOT of questions to people that know more than you. That’s what I do!
For example, if you want to learn about how APIs work, this is a great video to start with.
Also, if you end up using one of these products like Xano or Hasura, take advantage of the resources they offer you. You will be able to attend office hours and have demos with their product teams if you ask.
Ok, back to where we were. What happens after you create the database and the API?
You will have to do two things:
Populate your database.
Connect the database to Bubble.
If you already have the data, most services will offer you to upload it to the database in bulk, just like Bubble did. It will normally be a much faster process than with Bubble.
If you don’t have the data yet because it will be created when your users do something (e.g. when they connect their community to Community Copilot) then you can use Integromat to populate your database.
Once you have the data, you can either use the API Connector Plugin to connect to the API or use the SQL Database Connector Plugin to connect to the database.
But that’s a story for another day. If you’ve read until here and are interested in how to connect Integromat with Bubble or use these two plugins, let me know and I’ll make sure to cover it in the future.
App of the Week
This week I found one of my favourite Bubble apps so far.
GigCompare empowers gig workers and helps them to understand their pay. In the gig economy, platforms have assumed complete control over pricing in the name of efficiency and the ability to dispatch orders quickly, which has led to a complete lack of transparency.
It’s simple: workers should understand specifically what it will take to get the job done, and what they stand to earn from completing it.
How does it work?
Users choose the company they work for
They upload a screenshot of one of their income statements.
The app automatically reads the information in the screenshot and fills the fields, using Computer Vision and Natural Language Processing.
The app shows the Net Earnings Estimate, the Gross Online Earnings and Gross Active Earnings. It also has the details of the calculations so that you can learn how these numbers are obtained. Financial literacy applied to real life.
Watch this 8-minute Youtube video if you want to see a demo of the product. Or watch me try it in this 45-seconds GIF:
Note: You might be wondering how they make money. They don’t (yet). As they explain in their FAQ section, they plan to license the use of their proprietary Computer Vision and NLP technology and sell it to other businesses that serve gig workers, such as personal finance apps and mileage trackers. Read more here.
Tweet of the week
This week I’m sharing an experiment that Ben Sears ran to see what’s faster:
Getting data using an API
Fetching data from Bubble database
A bit more technical than usual but very related to the Makers Bubble.
Quoting Ben, If you are pulling a lot of data externally and are looking to optimize your Bubble application, caching the data in your Bubble database can net you a nice performance boost.
Ben, if you’re reading this, looking forward to more experiments 😉
This newsletter issue covered databases and APIs, topics I’m still learning about. If you find something to be inaccurate please reply to this email and I will make sure to make the corresponding changes. My goal is to help as many people as possible build new projects and make the most out of Bubble while learning in the process.
I hope you enjoyed reading this issue as much as I enjoyed sharing what I’m learning.
I would really appreciate it if you could let me know if you prefer this newsletter format (longer and more detailed) or the usual one (shorter and simpler). It will help me decide how to structure the newsletter in the future.
You can DM me on Twitter or reply to this email.
Thanks for reading!