Supabase: faster and better way to communicate

Hi there! I have some Supabase connections:

  1. Native WeWeb plugin (fetch collections), only dynamic.
  2. RestAPI to Supabase (may be used as static).
  3. GraphQL connection.

I have 3 types of tasks:

  1. I have static data from the table (user ranks).
  2. I have dynamic tables (products, users, profiles, transactions).
  3. I have user-related data.

:books: In first case: what’s better and faster? Static RestAPI or Supabase native?

:zap: Second one: I expect that native connection will be the better option, because it allows to use realtime databases.

:identification_card: Last one: here is a question: I need some dynamic data, which can be filtered to current user (his profile, referrer data and referrals). I can fetch all data and filter it via REST/Native (is it filtered server-side or client-side?) or I can fetch the entry with GraphQL query, setting the id as a variable and getting required JSON.

So can you share your opinions and best practices?

Hi @Antiokh!

Supabase native will receive a major upgrade in the next couple of weeks, it will really be the best way to consume your supabase instance.

Today some people fallback to REST API because of missing features, its not really a performance issue.

Static is not that useful since we released dynamic pages (with variables in path) and native backend filters for supabase. The only thing where static is better is to create static collection page for SEO purpose, but it come with his own drawback (you will need to publish again each time you expect your collection to update).

For the filters, with our native integration it will be handled backend side by supabase, so you will receive only the relevant data.
With REST and Graphql it will depend of their API, it they allow you to send parameters through queries to apply filters and the available endpoints. The filters system you see on dynamic collection for REST and Graphql (the last step) are applied in the front end.

4 Likes

The main advantage from graphql is that I can request some entry by id and get a json, not a collection. It is useful for some javascript actions. And now when I load some data from Supabase, GraphQL request by id somehow works faster.

Thank you for explaining, I’ll focus on native integrations and will be waiting for Supabase plugin upgrade (and Push messages, really need them).

1 Like

Alexis, by the way. Do you plan to add a function call for supabase? I’ve made a lot of necessary PostgreSQL functions, but as I know, I can call them only with API. Or set some column in auth.users, updating its content on every call (like metadata).

You can call them with REST API, or you can use the SupabaseAuth exposed instance to trigger it with the JS SDK

1 Like

Yes, planned :+1:

1 Like

Can you show any example of JS SDK usage? Any video tutorial.

You might want to look here on the forum, there is many topics about using the exposed sdk instance

1 Like

Sure, I was hoping that you know any topic that has a good solution without digging the whole forum.

It’s fairly simple,

you can use let supabase = wwLib.wwPlugins.supabaseAuth.publicInstance to set your supabase variable, and then follow the v1 documentation (WeWeb for now still runs on the v1 SDK) and use it as you normally would with Supabase in any other case.

1 Like

Thank you, I’ll try it