Yes, when WU pricing was announced that is when people started to talk about Supabase or Xano as a backend for reducing WUs. The problems there are you still do have costs for API calls and added complexity for user data types, passwords etc. and are adding in another service layer (Xano or Supabase). This does not require any 3rd party systems nor does it add any complexity to working with User data types in Bubble as everything this plugin does is in Bubble and uses the existing Bubble database.
The value proposition of the plugin is not just it’s ability to reduce WUs for creating or fetching data. Saving Workload Units is what led me to finding my way to building it, but there are so many benefits that go way beyond just saving WUs. It opens the door for functionality that is not as readily available to most non-technical developers. I’ll be adding lots of content around how the plugin expands current functionalities.
If you are starting from an existing application and want to utilize it to reduce WUs on searches, depending on how complex that data type is woven into your app, is how much wiring in needs to be done. For example, I have a data type that is used just for searching, for SEO purposes, that eats 200,000 WUs a month. The data is never changed, so I have one reusable element as a ‘card’ and a page that displays the search results. All I needed to do was create my objects in api connector, extract from DB my 2,000 items as JSON, then pasted into a data jedi element, and ran a save operation to my database to save those objects. Then just remapped the data field values for the ‘card’ and the search.
If starting out with a new app, it can save you some time as you can do things like have a global data center.
It does not work with inputs that are set to autobind because autobinding automatically changes the values in the DB…but you can create an ‘autobinding’ type of functionality.
I would not recommend this for every single data type to be transformed into an api connector object. There are use case examples that Data Jedi with the api connector object approach are not suitable and some where it is great. Best examples generally are data types that are controlled by one individual user, changed infrequently, do not need multi-user editing real time updates.
Despite my recommendation, the plugin can still take a database data type and format it as json (put into data jedi element field) and be created as a api connector object, which those can be manipulated and saved back to the database, so likely does work with real time updates with multiple users…I just caution it at this point as it is all very new and I have not personally used it that way yet.
Data doesn’t go anywhere. No 3rd party processors introduced.