3. Client-Server Communication
• The Communication is initiated by the Client-Side WebSocket
Module
• After the Connection has been established the client will emit a
message of type:
(“Init Query”, Query)
• It will also start listening for messages of type: Query
• When that message is retrieved by the Server the client’s session
will be added to the group Query:
• Groups can be implemented as a hash map (Query ->
session_list):
– If the Query group already exists, the new client will simply be appended to
the group
– If it doesn’t, it will get created and added to the hash map
• The Query will be evaluated and the result will be emitted to the
client using a Construct Diff
5. Client-Server Communication
• The IVM Module at some point will generate a diff for a
given Query
• The WebSocket Module will utilize the hashmap to retrieve
the session ID’s of the clients that listen for changes on the
particular Query
• It will propagate the diff to them (Eager Propagation)
• Upon retrieval the client will simply add it to the log
• Keep separate logs for each type of diff (Insert, Update,
Delete)
• A Batching Module should be implemented to provide
support for Lazy Propagation
7. Proposed Client-Server Architecture
• Use socket.io to enable communication between server and
client
• Ideally utilize RequireJS as a module loader on the client. On
the server-side we are somewhat flexible (RequireJS,
CommonJS etc)
• Use Karma for unit testing (as much as possible…)
