WS(S) protocol netdata

proposal.md

Message container

Client message

  {
    cred: {
      token: string, // could be JWT or some kind of session token
      stateCheckSum?: string // md5 or any. Used only in sensetive cases
    },
    action: {
      name: string, // Good idea to use the same action name as in redux
      callBack?: boolean,
      callBackName?: string, // Action name to be fired on response default value action.name + _DONE
    },
    payload: JSON | GraphQL query | any
  }

Server message

  {
    action: {
      name: string,
      checkSum?: string
    },
    payload: [ data ], // Good idea is to use list contecxt in case of mapping data
  }

Message types

• DIRECT - will be sent to exect connection
• PERSONAL - will be sent to all user connections
• GROUP - will be sent to all users and all user connections in group
• BROADCAST - will be sent to all connections in system

DIRECT

• UX based message, switch of tab, node or any
• server request for user-agent
• request for refetch data

PERSONAL

• switch locale, or theme of app or layout
• notifications
• server PUSH message

GROUP

• Notification of new user connected
• Alerts of all kinds

BROADCAST

• System messages
• Cluster issue messages
• Reboot warning

Name consistency

In case we have the same names for redux and requests we could get the benefits:

• strait mapping of client and server actions
• consistent application
• posibility to conctrol browser app from server by sending correct actions
• state time traveling (we can reconstruct client state of any time, coz we have all, the action names and the payload)
• sharing of frontend state between different clients
• action list could be moved to config file/repo/src with persist documentation
• higher level of abstraction over communication

Fallback to HTTP(s)

Could be implemented in case we use POST messages for all requests.

• duplex connection could be emulated over long polling

Env and version settings

As far ws(s) connection provided by proxy we can get next benefits:

• after successful connection setted up we can select API version end execution env context like (dev\staging\prod)
• backend communication could be changed any time wihout changing the frontend part, coz all of this methods hided in middleware (ws(s)) proxy

{
  action: {
    name: "@@APP/BACKEND_SETUP/ENV_SET"
  },
  payload: {
    api_version: 4,
    env: "develop"
  }
}

Server connections

interface IConnection {
  apiVersion: string,
  userId: string,
  connectionId: string,
  sessionId: string,
  connectionOpenedAt: number
}
 
const userConnections: Map<string, IConnection[]> = new Map();