I’m thinking that this could be a good feature to add to the plugin: a kind of “Update local” action that allows updating the data locally (row). Then, when you’re ready with the update, you can simply call the “Update” action.
You can already do something similar for bulk data (List) with the Bulk state and the “Add item to bulk data” action.
Bulk demo
I’ll check this and let you know if I could implement a better alternative than using custom state in a later version.
By default, users need to confirm their emails. So, you’ll need to call the “Verify OTP” action in order to log in.
If this is disabled, then you should get the user session right after signing up.
You can update this settings on: Authentication > Providers > Emails.
Super helpful! meant on the status code - how do I get the alert flashing up depending on whether the User has been signed up successfully fully / not?
Hello @Nass I am trying to purchase your plugin but got an unhelpful error from Bubble when I entered my billing info saying “Unexpected server error: please report the code parameter to the team”, but no code parameter was given.
Would be handy to store a jsonb, edit this in bubble by means of workflow (plugin perhaps) and push that jsonb back when needed. Using custom states especially with multiple columns feels scary to me
Hey @sem,
Thank you for the feedback. That’s actually the plan!
In the next plugin version, there will be a new state on the DB component and a new Patch action that you can use to update the state in workflows. You will then be able to use the final payload in the DB actions.
I’m at the early stages of considering moving our DB from bubble to supabase as per conversations between myself and my developer friend, your previous comment about separation of the two makes sense and also keeps in line with the simplicity of making front end changes and the limitations on the buble backend or the WU costs associated with complex queries or large dataset filtering…
as I say I’m at the early stages and by no means a developer, more like and enthusiastic amateur (but I have our bubble app on Apple and Android stores) couple of questions which hopefully are just confirmations of the previous posts…
I’m proposing moving all our tables and DB to sup abase for portability perhaps later on…
I assume that we can replace anywhere in our app that has a ‘do a search for’ and then point this to the sup abase DB and compose the query in the plugin either via the filter or the advanced filtering (which may require a little knowledge on how to write the query) - so anywhere we currently search we just ‘find and replace with the equivalent’
how have you dealt with privacy rules in sup abase? in bubble it’s pretty easy to see what permissions a user has to each table etc? is it as simple?
I assume the ‘do a search for’ and ‘make changes to…’, ‘create a…’ and ‘delete a…’ again are all simple features of the plugin where we just rewrite the existing bubble logic into the new sup abase query equivalent?
have you had to make any changes to database structures when moving from bubble to supabase, were there any constraints in bubble that you found to be much simpler in supabase and vice versa. I think we have a couple of tables that we needed to out in due to limitations in bubble.
do you have any stats on the performance improvements of overhead on using an external database, either in speed or costs?
We are just doing what you would like to start. My 2 cents
Basically, what we have done is setup a view for important current_user type of fields. On page load we populate a group_datasource in bubble with the content of the body that we get in return from calling the view in supabase. Next we populate custom states on an element. My advice would be to think this through. You want to organise custom states that hold data to be used in your app in an easy to find and maintanble way. splitting up custom states in various elements might be wise depending on your use case. for instance the following custom state groups (meaning, an element that you only use as keeper of the custom states) 1. access_states (does and if so to which part of the app has the user access 2. setting_states (thinks like language, metrics, darkmode etc) profile_states (things like email, name, image(s) etc). The reason is that you want to push data into custom states is that from there on it remains the same. So should you in any point of time change the source data you only have to push the new source data into the custom state and the app will work. Also, when you want to update something, just update the custom state and as soon as the page reloads for whatever reason the custom state will be populated again if you make sure that you push the changes to supabase of course as well.
RLS in Supabase is just like that of bubble, both postgres. Just remind yourself that when your users are in Bubble and not in Supabase it is a bit harder to say something like “when current user is the owner of”
I do not use a plugin, just api calls, but it will probably be the same with the plugin. At some stage you want to fetch data, at some stage you want to push data. Use custom states to hold the change on the device between push and fetch of supabase data.
Once you get to know Supabase and in particular postgres alot of things get easier, faster and cheaper. One important advise…talk to @lindsay_knowcode because I think he can get Supabase up and running quickly. Bubble places caps and spaces in field and column names which postgres does not like. Get rid of those first before moving data to Supabase
Did not calculate it because we knew it is a no brainer. Try to delete 10.000 rows in Bubble. it will take you a long time. Supabase it will be a second or so. Also, for us very important, what you do in supabase is forever yours. You can go where you want. Not so with Bubble.
Privacy rules
The equivalent of privacy rules is row-level security. You’ll need to enable RLS on your tables and define policies for select, insert, update, and delete actions. The process is not complex and you’ll find many resources available (e.g Row Level Security | Supabase Docs)
CRUD
Yes, you can replace Bubble operations with Supabase equivalents.
do a search for → Fetch
make changes to → Update
create a → Insert
delete a → Delete
These operations will be checked against the RLS policies you have defined for your table.
Limitations
I’d love to know more about the limitations you’ve encountered.
Supabase, being based on PostgreSQL, you should be able to model almost anything with it.
@Nass one thing that I still try to figure out how you can use RLS in Supabase when you do not have the user table in Supabase. How would you setup RLS in Supabase with users in Bubble?
You must generate and sign JWTs on your own and use them when calling Supabase endpoints.
Then you can define RLS policies that will inspect the current JWT attributes (role, sub - user ID, etc.). You can also define your own auth.user_id() function to be used later in RLS policies.
For example:
create or replace function auth.user_id() returns text as $$
select nullif(current_setting('request.jwt.claims', true)::json->>'userId', '')::text;
$$ language sql stable;
PS: I’ll integrate this in the next version (a “Generate JWT” action and a new field to set your own JWT).
I’m working on a Bubble app where users can log in using social media accounts like Google and LinkedIn. I need to retrieve the user’s first and last name during the login process. Could anyone guide me on how to achieve this using the Supabase plugin? It seems the Supabase element states don’t allow it.
Any guidance or examples would be greatly appreciated!
Make sure to set the field Identity to “Identity (Supabase)”
The plugin will then expose the values retrieved from the identity linked to the user (Google, LinkedIn, etc…) on the auth state “identities”
If you have multiple identities linked to a user, you can filter using the provider field.
For example, for the Google provider: