feat: optionally configure stream method to use a private channel#1357
feat: optionally configure stream method to use a private channel#1357
Conversation
There was a problem hiding this comment.
Pull request overview
Adds an opt-in way to configure the Realtime channel created by .stream() so callers can use private channels when their Supabase project disallows public channels.
Changes:
- Add optional
RealtimeChannelConfig? channelConfigparameter toSupabaseQueryBuilder.stream(). - Thread
channelConfigthrough stream builder classes and pass it intoRealtimeClient.channel(...). - Update stream docs to mention the new configuration option and refresh a replication doc link.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| packages/supabase/lib/src/supabase_query_builder.dart | Exposes channelConfig on the public .stream() API and forwards it into the stream builder. |
| packages/supabase/lib/src/supabase_stream_builder.dart | Stores the passed channelConfig and uses it when creating the Realtime channel for Postgres Changes. |
| packages/supabase/lib/src/supabase_stream_filter_builder.dart | Propagates the new channelConfig constructor parameter through the filter builder wrapper. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| SupabaseStreamFilterBuilder stream({required List<String> primaryKey}) { | ||
| SupabaseStreamFilterBuilder stream({ | ||
| required List<String> primaryKey, | ||
| RealtimeChannelConfig? channelConfig, |
There was a problem hiding this comment.
I think is better to add a new config type specific for configuring stream which contains only the private field, since the other ones doesn't apply here, and may confuse users.
Something like StreamChannelConfig.
There was a problem hiding this comment.
Yeah sounds valid as well. But since there is just one option for the moment I would propose to use just 'private' as an additional argument to 'primaryKey' and leave out the additional class. What do you think?
What kind of change does this PR introduce?
feature
What is the current behavior?
Realtime channels that are created by the
streammethod are always public, which can be an issue if a project configuration is enabled to only allow private channels.What is the new behavior?
One can pass a realtime channel config to the
streammethod to allow making a channel private.Additional context
I chatted with a member of the realtime team and discussed something like this to be a reasonable solution. It is not possible to make all channels private by default as it is done in #1324 because even without actively using the broadcast channel, the RLS on the
realtime.messagestable needs to allow the joining for broadcast. So it needs to be decided by the library user whether a channel should be private or not.close #1311