Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Subscribe to Views / Multiple Rows / Multiple Columns

See original GitHub issue

Feature request

I would like to subscribe to a query itself, not a table. I don’t need multiple subscriptions, just one for the query. If the query changes (not always important if INSERT, UPDATE, or DELETE), I would like my observable to get updated.

Currently, we can only use this complicated subscribe version of this query:

Promise

this.supabase.from(col).select('*').eq(field, value).single()

Subscription

this.supabase.from(${col}:${field}=eq.${value}).on('*', (payload) => {})

Is your feature request related to a problem? Please describe.

The eq should be a separate method
Every other method on the promise version should be available (gt, ls, filter, like, etc).
Views should be available for subscriptions (NOT CLEAR AT ALL)

Describe the solution you’d like

this.supabase.from(col).select('*').eq(field, value).single()
  .subscribe((snap) => {
    if (snap.type === 'added') {
     console.log(snap.data);
    }
  });

V2 is Getting MORE Complicated, and LESS Intuitive

https://supabase.com/blog/supabase-js-v2

supabaseClient
  .channel('any_string_you_want')
  .on(
    'postgres_changes',
    {
      event: 'INSERT',
      schema: 'public',
      table: 'movies',
    },
    (payload) => {
      console.log(payload)
    }
  )
  .subscribe()

While the multiplayer mode looks cool, let’s complete the actual limitations of the current realtime data before moving on to more features!

Channel names could be automatic (perhaps with UUID in the background) if we don’t want to select a channel.
These classes and methods are MORE confusing, and don’t help basic use cases.
This would also be useful in order to add GraphQL Subscription support.
I realize RLS is the biggest issue here.
Just allowing VIEWS to be subscribed to would solve this problem for now.

Describe alternatives you’ve considered

I don’t think there should be an alternative. In order for it to be easy, it should work just like the regular queries, but with a subscription.

All of these Database work the exact same way in Query mode as Subscription mode, and allow complex queries (as far as the database itself can handle):

Additional context

Issue Analytics

State:
Created a year ago
Reactions:3
Comments:7 (2 by maintainers)

Top GitHub Comments

3reactions

jdgamble555commented, Sep 27, 2022

Would love to hear more about this one. What do you mean by these classes and methods? How does it not support basic use cases?

The .on and .channel with the complex parameters where there is no documentation about options.

What seems easier to understand:

supabaseClient
  .channel('any_string_you_want')
  .on(
    'postgres_changes',
    {
      event: 'INSERT',
      schema: 'public',
      table: 'movies',
    },
    (payload) => {
      console.log(payload)
    }
  )
  .subscribe()

const mySubscription = supabase
  .from('*')
  .on('*', payload => {
    console.log('Change received!', payload)
  })
  .subscribe()

I understand the broadcasting feature seems pretty cool to have. However, you have over complicated the subscription process for people who just want to subscribe to the database. I don’t know that the broadcasting feature is really important or useful to most people when you could just store items in the database directly and subscribe to that. Perhaps a good compromise would be to add another method that emulates the promise method for postgres. This perhaps would call the unintuitive method # 1 that you have created for supabase-js-v2.

In most cases, I don’t need to think about a public schema, I don’t need to think about a channel name, and I don’t need to think about an event. I want to subscribe to:

All changes
The public schema
In postgres
And I don’t want to name a channel

The broadcasting feature is pretty cool, but we still don’t have the NEEDED features with postgres subscriptions.

There is a delay now in subscriptions !!! This should be fixed ASAP!
We cannot filter any of our subscriptions except for a simple eq filter? Firebase straight up can do more than this. A lot of your clients are moving from Firebase for the relational data support, and you can’t do relational data with real time subscriptions? a. Who decided to add the eq clause as a random string in a filter filter: 'body=eq.hey'? Why? Why would you do that, especially when you just wrote a new sdk version… b. Subscriptions should not work differently than postgres promises. In fact, I suggest you separate the broadcasting from the postgres subscriptions all together, as they are two different things. This would also solve # 1. But more importantly, let’s add all the filters that promises have shall we!
Besides a real hack of using RLS policies in certain circumstances, there is no real way to work around not being able to subscribe to your actual query. I don’t want to subscribe to all my data. I only want to subscribe to my query. I don’t need all inserts where x = y. I need a subset of those inserts, or any changes for that matter. There is no work around for that, and you guys are still talking about why subscribing to view changes are appropriate? This is HUGE!

Yes, web sockets in Supabase for the moment are very very limiting, and you guys don’t seem to have the fixes on your roadmap just yet.

Let’s change that please.

1reaction

w3b6x9commented, Nov 29, 2022

@jdgamble555 this is good feedback here: https://github.com/supabase/realtime-js/issues/185#issuecomment-1258851450. Will look it over and pass it on to the rest of the team. Also, what do you mean by postgres promises? Like the ability to perform db operations via PostgREST and get back a response on promise resolve in JS?