Websockets
Good choice:
- low latency (real time data)
- 2 way communication
- persistent connection
Bad choice:
- If you don’t need real time data, might be too much overhead
SOAP
Good choice:
- Financial and payment services
- Security and reliability are key
Bad choice:
- complex and verbose, so if not needed avoid it
REST
Built on HTTP methods
Good choice:
- Commonly known
- Easy
Bad choice:
- Real time data
- Highly connected data model
Graph QL
Not just an architectural style, but a query language.
Good choice:
- Minimizes data transmission (Client asks for specific data, gets only what they asked for back)
- Faster responses (due to limited data sent)
Bad choice:
- Steep learning curve
- Requires more processing on server side due to flexible querying capabilities
gRPC
Technically its a framework. The protocol is HTTP/2. gRPC web downgrades the protocol to HTTP/1.
Good choice:
- fast (uses protocol buffers to SerDe and send data in binary)
- can stream (bi directional communication over 1 persistent connection)
- can multiplex (can have multiple parallel streams over 1 connection)
Bad choice:
- if you have browser client (limited browser support)
Webhook
Good choice:
- event driven
- async
Bad choice:
- sync
- immediate response
HTTP long polling vs Websockets
Http long polling good when:
- communication frequency isn’t very often
- websockets can’t be used (old browser support, pre HTTP 1.1 support, environment doesn’t supportt websockets)
- infra can’t handle the number of persistent connections that would be used with websockets
Otherwise use websockets:
- persistent connections, so saves overhead
- 2 way communication
- faster (often used for real time data)
gRPC vs REST
gRPC:
- faster (less data transmitted because uses Protocol Buffers to SerDe data in binary)
- can have multiple, parallel requests over 1 connection
- can do 2 way connections
- CON: data not human readable
- CON: limited browser compatibility
- use cases: internal services, streaming
REST
- data in JSON so human readable
- good browser compatibility
- simplicity and ease of use are the priority
- use cases: public APIs, simple apps
HTTP 1 vs HTTP 2
gRPC vs Websockets
gRPC:
- Does not support streaming (multiple requests over 1 connection) or bidirectional communication with browsers because of reliance on HTTP2
Both:
- cross platform
- support bidirectional communication and streams (gRPC web supports neither though)
gRPC Web
gRPC relies on HTTP/2. Modern browsers can do HTTP/2, but still can’t give gRPC the level of control it needs. Old browsers can’t do HTTP/2 at all.
gRPC web is a client side server that translates HTTP/2 requests to HTTP/1 so the browser can handle them. This limits gRPC’s capabilities though.
gRPC Web does not support:
- bidirectional messages
- streams (multiple requests over a persistent connection)
RTMP
Real time messaging protocol
RTMP breaks video data into smaller chunks and sends them in a continuous stream.
Good for:
- The typical streaming protocol (twitch, youtube, FB live)
- low latency
Bad for:
- browsers don’t support it
HLS (HTTP Live Streaming)
Breaks the video into 2-10 second chunks and sends those.
Has a 10 - 30 second delay.
An extension, low latency HLS (LL-HLS) lowers the delay to 5 - 10 seconds by sending the stream in smaller chunks.
Good for:
- Client choose the quality they want
- Browser support
- Compatible with CDNs
- LL-HLS is pretty fast.
Bad for:
- Higher latency than RTMP (LL-HLS is only ~2 seconds slower than RTMP (3 - 10 seconds))
-
HTTP Long polling
Client sends request to server, leaves connection open waiting for response. When response received, connection closes, but the client immediately creates a new connection and waits for more data.
Not a true persistent connection, but basically is.
Connection only has 1 way communication while client waiting (only server can send data).
