Sockets
A socket is one endpoint of a two-way communication link between two programs running on the network. It allows real time, bidirectional communication between the web client and server. This allows for logged in users to see comments in real time without refreshing the page in a similar way as in Google docs.
Architecture
The GraphSpace notification system (pull request) sends users notifications when certain operations (such as graph deletion or graph creation) have been completed. In practice, many users (such as those in a large group) may receive these notifications, which involves creating database entries for each user. If we attempt to do all of these operations from the perspective of the user performing them. Thus, we elected to use Kafka (a messaging queue) to enable an asynchronous notification system. In the notification system architecture the notification has to be created only after a successful database operation of creating/deleting graph, creating/deleting group etc. In such cases the GraphSpace server then added messages to a Kafka queue that would then be consumed one-by-one on another server thread, which would add notifications to the database. The drawback of doing this is that if the Kafka queue goes down, notifications get dropped. But here in the comment system flow we only have to create a single database entry for a comment (rather than on per user), and we can directly send the comment via web-socket to the client once the comment is created, so we won't be using Kafka.
The GraphSpace notification system (pull request) sends users notifications when certain operations (such as graph deletion or graph creation) have been completed. In practice, many users (such as those in a large group) may receive these notifications, which involves creating database entries for each user. If we attempt to do all of these operations from the perspective of the user performing them. Thus, we elected to use Kafka (a messaging queue) to enable an asynchronous notification system. In the notification system architecture the notification has to be created only after a successful database operation of creating/deleting graph, creating/deleting group etc. In such cases the GraphSpace server then added messages to a Kafka queue that would then be consumed one-by-one on another server thread, which would add notifications to the database. The drawback of doing this is that if the Kafka queue goes down, notifications get dropped. But here in the comment system flow we only have to create a single database entry for a comment (rather than on per user), and we can directly send the comment via web-socket to the client once the comment is created, so we won't be using Kafka.
Architecture Flow Diagram
Comments
Post a Comment