Open Soviut opened 2 years ago
+1. I'm surprised this request hasn't gotten more comments!
This gets even more complicated if you want to allow messages to be edited, since that requires subscribing to the UPDATE event, then manually finding the message in the local chat history and updating it.
This is so key--the current way I use realtime means a lot of manual data mgmt, when the original query was so simple.
I think subscriptions for queries it could unlock a crazy level of productivity for supabase users. I've used the Firebase equivalent in production for years and found the DX amazing.
It's how Firebase subscriptions work, too:
As a consequence,
Example from Firebase docs:
import { doc, onSnapshot } from "firebase/firestore";
const unsub = onSnapshot(doc(db, "cities", "SF"), (doc) => {
console.log("Current data: ", doc.data());
});
How I would want to use this in a React app:
import { supabase, useQuery } from "db/supabase";
export function Chat = () => {
const messagesQuery = supabase.from('messages').select()
const [messages, messagesLoading, messagesError] = useQuery(messagesQuery, { realtime: true } )
if (messagesLoading || messagesError) return null
return messages.map(m => <Message message={m} />)
}
Example use cases:
Etc etc. There are plenty of realtime use cases already, my point is that ideally realtime should be the default.
Interesting, I could also use that. Subscribe to a query instead of 1 or multiple tables with filters. The way I'm tackling this is by creating a special-purpose table and subscribing to changes on this table. My mutative queries modify this table in order to trigger the subscribed clients.
I could use this feature as well
+1
+1
If this could be implemented it can be a game-changer.
Any ideas on if this feature is on the roadmap? This is also available in AWS Amplify: https://docs.amplify.aws/gen1/react/build-a-backend/graphqlapi/subscribe-data/
+1
Feature request
Is your feature request related to a problem? Please describe.
Queries and subscriptions need to be mixed for most real-time applications. However, their implementations are very different and return different results, requiring the application manually mix the two sets of data to keep them in sync.
For example, you might have a chat app that does an initial query for the latest 50 messages in the current chat room.
But in order to make the chat real-time, you need to set up a subscription that can only listen for inserts on the table. None of the querying operations can be used, only a rudimentary filter with different syntax. Likewise, the payload that is returned is simply the entire row with no control over which fields are sent.
This gets even more complicated if you want to allow messages to be edited, since that requires subscribing to the
UPDATE
event, then manually finding the message in the local chat history and updating it.Describe the solution you'd like
Extend the query syntax to allow subscribing to a query.
The idea being that unless a change to the table affects the query, don't send a payload.
It would be useful if both a full payload and a sparse payload could be chosen. Full payloads are good for things like real-time chat where you need old messages to be truncated, so replacing the entire immediate chat history can be beneficial. A sparse payload is useful for surgical changes to a local dataset, when the data is potentially too large to resend each time there is a change.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
This feature request is similar to subscriptions in GraphQL which use the same syntax as normal queries. It would be really great if subscriptions could be added to the GraphQL API as well.