Push pull techs

short polling

The client (consumer) sends a request every N seconds

• pros

  • it's easy to understand
  • it's easy to implement

• cons

  • difficult to define a proper value for the interval
  • increased number of empty responses (or not new data)
  • this ends up, to consume resources on the server (broker side)

• resources that used for every client (consumer) request

  • connection management
  • authentication/authorization
  • rate limiting
  • TLS termination
  • request validation
  • ...

long polling

if there are messages to the queue server (broker) sends the message to the client immediately.
A connection is kept open for a specified interval (this is specified from the client).

• pros

  • less resources consumption
  • reduces the number of empty responses

• cons

  • not good when you client expects immediate response from the server (broker)

web sockets

• upgrade header included/required (both client and server)!

• pros

  • bi-directional
  • re-uses the initial TCP connection
  • fast

server-sent events

You can imagine it as a server job runs periodically that sends messages every time a message is available (similar to long polling).

• use cases

  • live feed
  • client progress
  • logging

• pros

  • simplicity
  • compatible HTTP and HTTP/2 (this is not possible with web sockets)
  • lightweight (no extra headers)
  • Firewall friendly

• cons

  • proxying is tricky
  • one way direction
  • open connection for a long time
  • stateful, difficult to scale horizontally

(Content-Type: text/event-stream)
("data: " + mydata)