11001
Questions

Methods of interaction between client and server

Methods of interaction between client and server

HTTP/HTTPS

(REST APIs)

explain architecture shortly (GET/PATCH/PUT/POST/ DELETE for updates)

PUT/ PATCH - PUT entire instance update, PATCH partially updates

Principles (find all principles):

  1. Serverless

  2. Send response in JSON (Only?)

  3. Caching

  4. Layered architecture

Standard request-response protocol. Client sends requests, server responds.

  • Use case: CRUD operations, typical web APIs

  • Pros: Universal, stateless, cacheable

  • Cons: Request overhead, no real-time support

    GraphQL via http/ https



RPC (gRPC, tRPC)

High-performance RPC framework using HTTP/2 and Protocol Buffers.

  • Use case: Microservices, low-latency requirements, polyglot systems

  • Pros: Fast, strongly typed, bidirectional streaming

  • Cons: Limited browser support, binary format

-- Real time communication methods

WebRTC

Peer-to-peer communication with optional signaling server.

  • Use case: Video/audio calls, file sharing, real-time gaming

  • Pros: P2P (low latency), media streaming support

  • Cons: Complex setup, NAT traversal issues

Web Sockets

Query language allowing clients to request specific data structures.

  • Use case: Complex data requirements, mobile apps, multiple data sources

  • Pros: Flexible queries, single endpoint, prevents over/under-fetching

  • Cons: Learning curve, caching complexity

Event Sourcing and Server-Sent Events (SSE)

Unidirectional push from server to client over HTTP.

  • Use case: Live notifications, stock tickers, news feeds

  • Pros: Simpler than WebSockets, auto-reconnect, built-in event IDs

  • Cons: One-way only, HTTP limitations

Regular (Short) polling

Short Polling

Client repeatedly sends requests at fixed intervals, server responds immediately with current data (or "no update").

How It Works:

  1. Client sends request → "Any updates?"

  2. Server responds immediately → With data or "no updates"

  3. Client waits fixed interval (e.g., 5 seconds)

  4. Repeat from step 1

Long Polling

Client repeatedly requests server until new data is available.

  • Use case: Legacy real-time needs, fallback mechanism

  • Pros: Works everywhere, simple

  • Cons: Inefficient, high overhead