How to: Fetch Data

Getting Data from Supabase is done automatically based on your setup.

Let's look at a very simple scenario that you'd like to fetch from a table called 'User'. This is the recommended way of saving User data similarly how Bubble does it for you. Before anything happens let's head over to Supabase for the initial setup.

Let's setup a simple user table with fields like: First name, Last name, Phone Number. Since we don't have some things setup for us by default like in Bubble, we need to add another field which references the actual authenticated user from auth.user

This is a basic foreign table relation between public.user and auth.users. The example also shows that the created_by fields shows the Unique ID of the Authenticated user which Supabase Generates for us.

You can also see how in the setup it says "On delete: Cascade". This means that if the User deletes their profile from auth.users (in the plugin it's the "Delete User" action) the related row in the public.user table will be automatically removed, you don't have to create a separate action within your app.

Row Level Security Setup

Let's see the Row Level Security Side of it. Here's a very basic setup which allows the User the entry blongs to read/write access:

This rule targets authenticated users only since anon user won't have accounts anyway, and it uses a simple expression

(auth.uid() = created_by)

Supabase sends the User related information with every request you make to your Database, this includes the email, JWT or Unique ID.

And since we know we can exctract the information from the request we can say that if the UID of the Auth from the request matches the UID in the created_by field, you can do the rest of the action.

Now that's done let's head over to Bubble for the Setup there.

Plugin Setup to fetch Data

Let's add a New Supabase Data element so we can start building our search query. Head to the Editor and search for Supabase Data, and add that to the page.

Let's look at the data setup first:

• Table: it's "user" since this is how we named it in Supabase, it needs to match.

• Columns: is just an asterisk or you can leave it empty to return all data. We talk about advanced queries here.

• Data Type: Choose the Data type from the Dropdown. It needs to match to the same one which you've added via the API connector, since that's our reference.

• Prefix: Can be ignored

• Count Type: Count algorithm to use to count rows in the table or view. "exact": Exact but slow count algorithm. Performs a COUNT(*) under the hood. "planned": Approximated but fast count algorithm. Uses the Postgres statistics under the hood. "estimated": Uses exact count for low numbers and planned count for high numbers.

• Count Only: This means that the plugin won't return any Data, no matter what, but shows you based on your query how many rows it would return. This is the exact equivalent of using the :count operator in Bubble.

• Enable Realtime: If you'd like to listen to changes using Supabase's realtime feature. This means that if in the Database something happens wheather you do that manually, or another person make changes, Supabase listens to those changes and sends it to the clients. We go into more details here.

• Channel name: a unique identifier for the user who wishes to listen to the Database changes

• Realtime Filter Type: Supabase support less filter for Realtime, choose the most appropriate.

• Realtime Filter Name: Needed to construct your Realtime query Filter

• Realtime Filter Values: Needed to construct your Realtime query Filter

• Order the Results: If false Supabase will just randomly send back the data to you. Having said that you can absolutely use Bubble's own sorting mechanism which is just as fine.

• Order By: Column's name to order the results by

• Ascending: True or False

• Limit to a range: This is basically the Pagination feature. True or False. (The from and to values are 0-based and inclusive: range(1, 3) will include the second, third and fourth rows of the query.)

• Start Number: For the Pagination, to get the first item it would be 0.

• End Number: How many results you'd like to return.

• Filter Type: Choose the most appropriate filter. The full list with examples is here

• Filter Name: Needed to construct your query Filter

• Filter Values: Needed to construct your query Filter

Filter: In our example we only Used 1 filter since it's enough for us. This means that the created_by field has to match our Logged in User's Unique ID.

• Multi Filter: you can add a valid JSON, if you'd like to add separate filters and you'd like to match for multiple columns. (will be deprecated soon)

• Any Filter (beta): This is an advanced field, where if you've ran out of the 5 added filter limit, you can add more. This input can take any filter.

• Expected JSON Response: Check the full explanation here.

In our example we try to get the User data but we shouldn't fetch that data if the User is logged out. As soon as the Auth element has the UID we know that the user is logged in. So what we can do based on that is that we don't show the Data element on page load, only once Auth has the UID not empty:

This means the Fethching will only happen once the related value has been filled.