🚀 Feature: Realtime Query Listening

[sanny-io]

🔖 Feature description

Firebase allows you to actually listen to query results. If the results of your query would change if you ran it again, you are automatically given the latest results of your query in realtime.

https://firebase.google.com/docs/firestore/query-data/listen#listen_to_multiple_documents_in_a_collection

🎤 Pitch

This would allow realtime capabilities to be used with filters and offsets and such in a very simple manner.

👀 Have you spent some time to check if this issue has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

[TorstenDittmann]

Interesting idea, not sure about a possible implementation. Especially since our realtime server works with all services and resources of Appwrite - not just the Database.

Something like this is already possible with the current solution - just not out of the box and completely optimized.

I will keep this issue in the backlog for the future 🙏🏻

[Re-Shard]

This is definitly an interesting feature. At this moment there are to few options to listen to changes on the DB.

[superseby2]

+1 adding filters to collection subscription would add a lot of flexiblity.

[stnguyen90]

Related discussion

[merabtenei]

You can do that now but it's not straight forward.

make a listDocuments on a collection with some filters.
listen to changes on that collection
check if the payload corresponds to the previously set filters
update the list based on what event was received.

It would be great if we had something like in Firebase by doing all this on the background either on the server side or client side through the Sdk.

[Andrey253]

One of the solutions. I create collections by parameter name and write objects with the appropriate parameters to them. And I listen to collections with the parameters I need. If the parameter changes, delete the object and write it to another collection. I don't know how much I clearly put it.

[sanny-io]

This could also be done on the client side ? You can do that now but it's not straight forward.

make a listDocuments on a collection with some filters.
listen to changes on that collection
check if the payload corresponds to the previously set filters
update the list based on what event was received.

Yes, the 3rd step is the crucial one that doesn't have a general solution with the current implementation.

I don't think this can be done on the client at all in a way that is scalable, especially not with limited resources on mobile devices.

One of the solutions. I create collections by parameter name and write objects with the appropriate parameters to them. And I listen to collections with the parameters I need. If the parameter changes, delete the object and write it to another collection. I don't know how much I clearly put it.

This is very clever, but would quickly grow unmanageable for more complex apps.

[DmitryGrigorov]

The best idea to convert all sdk methods to REST API Queries and use axiosInstance.interceptors from axios npm package.

[ElmcHostedApplications]

This feature for realtime update based on query is needed. Example I may have a collections called States then I may have attributes called city, zip code, etc. In my React application I may have filters where I only want to subscribe to changes only if a zip code matches in the database

[WasserEsser]

This is a very necessary feature for realtime use.

Imagine a live-ticker scenario.
You have multiple simultaneously running games and a collection that will hold all the game events.

Subscribing to the collection means you get all events from all games, while you may only be interested in 1% or less of them. Pushing out all events to all clients has a huge impact on performance. The wasted bandwidth on both the server and the clients is unacceptable, so the Realtime feature of appwrite cannot be used.

Being able to apply queries to the subscription would eliminate this.

[merabtenei]

@WasserEsser, that's not completely the case, each user will only receive updates from objects he has permission to view. With correct permission handling by your app, each user would receive only updates that he is granted to access, that may still be more than what you really need depending on the use case but IMO it's acceptable enough and realtime can indeed be used with proper permission management.

[WasserEsser]

@merabtenei You completely missed the point of my post. It's a live ticker. Anyone has and should have access to any game they want to see. Dynamically granting and revoking access based on which game you clicked on is not a solution, it's an awful dirty hack. If there is no way to do it properly, appwrite is not the solution for this use-case.

[xuelink]

Up

[xuelink]

@WasserEsser, that's not completely the case, each user will only receive updates from objects he has permission to view. With correct permission handling by your app, each user would receive only updates that he is granted to access, that may still be more than what you really need depending on the use case but IMO it's acceptable enough and realtime can indeed be used with proper permission management.

@merabtenei I asked this question today in discord live event like that are you planning to add this feature in future. They suggest me to use permissions as well. I dont have any deep experience with permissions but i think while creating a document, im able to put permission which is related exactly current user. If it works as expected, then no need to have this feature/issue. Websocket is going to send you only related updates.

[WasserEsser]

@WasserEsser, that's not completely the case, each user will only receive updates from objects he has permission to view. With correct permission handling by your app, each user would receive only updates that he is granted to access, that may still be more than what you really need depending on the use case but IMO it's acceptable enough and realtime can indeed be used with proper permission management.

@merabtenei I asked this question today in discord live event like that are you planning to add this feature in future. They suggest me to use permissions as well. I dont have any deep experience with permissions but i think while creating a document, im able to put permission which is related exactly current user. If it works as expected, then no need to have this feature/issue. Websocket is going to send you only related updates.

Again, this is not a solution. Using permissions to scope events should be done for their exact purpose, blocking people from receiving events they have no right to access, while in my case, they have every right to access them, they just don't want them.

This feature is very necessary.

[rohankm]

waiting for this feature

[moshOntong-IT]

waiting for this feature

[moshOntong-IT]

Since realtime gives us a payload, but we would like to have something middleware or a filter method in Realtime subscribe that will have conditions something like for sample Query("consultType", "adasd"), then the server side will check it first if the payload contains this attribute then check if equal to this value. Since the realtime works with all service not only Database, but the thing is we have payload key from the Realtime response then we can use this. We can do this in client side, but it prefers that server side should handle this.

[jovazcode]

waiting for this feature