Feat 265 *platform wide* realtime support #692
Conversation
| @@ -30,6 +30,19 @@ | |||
| $response->json(['version' => APP_VERSION_STABLE]); | |||
| }, ['response']); | |||
|
|
|||
| App::get('/v1/health/realtime') | |||
There was a problem hiding this comment.
This route is only used for testing and will be deleted later.
|
May I ask where the need for multiple real-time protocols comes from? |
|
@TorstenDittmann not much of a need, but more of a possibility. Seems to be pretty easy to support multiple protocols using Swoole. This also have a very good fit with Appwrite agenda of being tech and platform agonistic, and might allow new use-cases. There were a few mentions in the community about MQTT and Websocket, I guess that will allow easier integration with Appwrite for platform that are already comfortable with a specific protocol or client SDK. Obviously we'll start by supporting 1 protocol. |
|
I see nothing explicitly wrong with this code for now, since it is a starting point anyway. The plan is that all possible functions that are normally requested via HTTP are also accessible via the realtime protocol, right? Also, have you figured out a plan to manage connections and subscriptions yet? Amazing work! 👍 |
@TorstenDittmann I'm still thinking about it, not sure how the message request will look like, maybe something similar to GraphQL or GraphQL itself? I was thinking of starting with a read-only mode where users can subscribe and receive events and use it in combination with the REST API. What do you think?
This is what I'm thinking about. I'm gonna use a hashmap of all the users where the key is going to be the connected user ID and the value is going to be a hashmap of channel names and the user connection ID, like this: Every new event message will do a hash lookup, which should be pretty fast, find all relevant users, check if they have subscribed to the messages, and then send the message if relevant (if the user has subscribed for it). The performance here should be O(N), where N is the number of "read" permissions in a resource [file/document/collection] - (@TorstenDittmann let me know if I'm missing something). Maybe we should add a limit to the max number of permissions? On each connection establishment, we'll verify the user has privileges to access that channel. We'll remove the connection ID on every connection close event or on specific failure errors. For channel logic, I had this in mind: (but I'd love some feedback)
|
|
@eldadfux I think that adding realtime feature to Appwrite will be a great addition, just a few things to keep in mind:
Let me know what you think Josh |
|
Thanks for the feedback @joshdvir! About the points you raised:
|
|
@TorstenDittmann are we OK to close this PR in favor of #948 ? |
Yes, we can close this one. |
What does this PR do?
Adding realtime server for allowing live updates and interactions with the Appwrite platform.
The server will include multiple realtime protocols support including (in order of priority):
This PR is still a work in progress. Stuff still yet to be implemented:
Test Plan
TODO: add new set of tests to both test connection establishment and stream functionality. Trigger mock event, assert payload is correct on each listener.
Related PRs and Issues
#511
#265
#509