Bubble is a very powerful platform for building no code web applications. It’s chock full of features that help even the most code allergic developers out there to build fully fledged applications, quickly and easily.
One of the hallmarks of Bubble is that not only does it allow you to construct your application’s UI and business logic (using what they call workflows) — it also has a fully fledged database you can use to store your application’s data. While on the surface this seems like a dream come true: one platform to rule them all! In reality, this sort of setup can become incredibly difficult to maintain.
There’s a reason that code applications are split into multiple different front ends (web, mobile, tablet, etc.) and a back end.
Having both the front end and back end separated from one another forces you to come up with some sort of contract between the two ends: a familiar language they can speak to one another where they will understand each other. A lot of no code developers may consider this to be excessive.
Why do this extra work?
What is the payout for this?
We should be building and shipping!
The problem that tends to occur, is what I like to call: logic bleed. Applications are built on logic, and there are front end specific logical problems, as well as back end specific logical problems.
At a certain point your application becomes so complex, that you’re finding your once elegant database is littered with all sorts of data necessary for front end logic, smashed right into the real core data that you need to actually deliver the application to your customers. The opposite also occurs: the front end has to be aware of all of the eccentricities of the back end. In the coding world this is called spaghetti code. And no, it does not taste good. No code apps are not immune to this: and oftentimes it can look even worse in no code form than in code form.
When you scale up even further, to the point where you need multiple developers to actively develop and maintain your app, you run into situations where every developer needs to know every darn thing about how the app works. Front end, middle tier, back end.
As your app continues to grow, you’re finding that productivity slows to an absolute crawl as it takes multiple developers to figure out one little bug. We’re all human, boss: we can’t know every small little detail about how a large application works.
This is why logical separations exist: front end, back end, middleware, data access. You can draw the line at many different points. The main point I’m driving here is that you should actively consider drawing the line early in the development process, so that you don’t face these growing pains later on when you need to scale fast.
So where does SheetDream fall into this equation?
SheetDream can act as the back end for your Bubble app: with your database either being Airtable or Google Sheets.
You can use the wonderful API Connector to get Bubble talking to SheetDream. You can adjust the body of the request that you send for POST/PUT/PATCH requests to match what SheetDream expects, and Bubble’s JSON response mapping works beautifully with the responses SheetDream returns.
Lets face it, you want that Bubble data sent to Airtable or Google Sheets at some point anyway. You don’t want to run queries and analyze the data within Bubble itself. That’s just a painful process.
But wait a minute here! Isn’t there already an official Airtable integration for Bubble? Why the third party?
The existing Airtable integration for Bubble has been deemed unreliable by the Bubble developer community. It is plagued with a handful of bugs, usually around writing from Bubble to Airtable.
This sort of thing has befuddled Bubble developers for quite some time, to the point that most of them wind up calling the Airtable API directly. Of course, when they do that, they eventually run into the dreaded 5 API calls per second per base rate limit issue for the Airtable API. Not to mention, their front end application logic becomes intertwined with how the Airtable API works: all of the paging rules, restrictions, and limitations that are imposed. Airtable decides to take their API in a different direction? Guess what, you’re rewriting that part of your app.
This is where SheetDream steps in: SheetDream acts as a middle tier between Bubble and Airtable, consisting of a caching database as well as a queue for slowly drip feeding your changes into Airtable without tripping any rate limits. This leads to dramatically improved performance: thanks to caching, as well as peace of mind that your app can scale without you having to add in logic to specifically get around rate limiting restrictions. You have control over your API and what it looks like. We take care of the communication with Airtable.
Among other benefits, when you build an API from your Airtable or Google Sheets data using SheetDream, the API that gets created for you is RESTful. It adheres to a standardized CRUD (create, read, update, delete) contract that has been iterated on for years in the API world, and is familiar to developers everywhere. The API is logical, allowing for ease of development and very predictable behavior.
More importantly, the API that gets generated looks very much like how an API would look if it were running on top of a real live actual database like PostgreSQL, MongoDB or Amazon DynamoDB.
What does this mean for you?
When it becomes the time to scale, and you need to move beyond Google Sheets or Airtable to a real database, doing so will be a trivial affair. You’ve already got the blueprint in the form of an API from SheetDream, you simply need to hire some back end devs to create a new API that adheres to the same contract: the same RESTful API structure that SheetDream created. This is a service we also offer to our customers as part of our Ultimate tier.
Want to learn more? Check out our other use cases. If you’d like to know more about how SheetDream could fit into your existing Bubble application, don’t hesitate to get in touch with us!
More Use Cases