Beyond REST: GraphQL, gRPC and WebSockets

REST isn't the only option

REST with JSON is the default for good reasons: it's simple, cacheable and understood everywhere. But some problems fit other styles better. You don't need to master these now — just know what they are and when to reach for them.

GraphQL: ask for exactly what you need

A mobile screen shows a customer's name, their last three orders and each order's product names. With REST that might be several requests (/customers/7, /customers/7/orders, /products/...), each returning more fields than needed.

With GraphQL, the client sends one query describing the exact shape it wants:

query {
  customer(id: 7) {
    name
    orders(last: 3) {
      total
      items { product { name } }
    }
  }
}

The server returns JSON in exactly that shape. Everything goes through a single endpoint (POST /graphql), described by a typed schema.

Strengths	Trade-offs
No over- or under-fetching	Harder to cache (no per-URL HTTP caching)
One round trip for related data	Clients can write expensive queries — need depth/complexity limits
Strong schema and great tooling	More complex server; N+1 problems need "data loaders"

In .NET, Hot Chocolate is the popular GraphQL server.

gRPC: fast, typed service-to-service calls

gRPC is a remote procedure call framework from Google. You describe services and messages in a .proto file:

service Inventory {
  rpc GetStock (StockRequest) returns (StockReply);
}
 
message StockRequest { int32 product_id = 1; }
message StockReply   { int32 quantity = 1; }

Tools generate strongly typed client and server code in C#, Go, Java and more. Messages use Protocol Buffers — a compact binary format — over HTTP/2, with built-in support for streaming in both directions.

✅ Great for internal microservice communication: fast, small, strongly typed contracts.
❌ Not directly callable from browsers (needs gRPC-Web or a gateway), and binary messages aren't human-readable.

ASP.NET Core has first-class gRPC support (dotnet new grpc).

WebSockets: real-time, both directions

HTTP is request/response: the server can't speak until asked. For chat, live dashboards, multiplayer games or collaborative editing, you want the server to push updates instantly.

A WebSocket starts as an HTTP request that's upgraded to a persistent, two-way connection:

GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade
 
HTTP/1.1 101 Switching Protocols

After that, both sides can send messages at any time over the same connection.

Alternatives: Server-Sent Events (server → client only, simple, plain HTTP) and long polling (an old fallback). In .NET, SignalR abstracts all of this — you call methods on connected clients and it picks the best transport (Track 11).

Scaling real-time servers

Each WebSocket keeps a connection open, so a user connected to server 1 can't be reached by code running on server 2. Real-time backends use a backplane (e.g. Redis pub/sub) to fan messages out across servers — you'll design one in System design basics.

Choosing

Situation	Good fit
Public API, CRUD-style resources, many unknown clients	REST + JSON
Complex UI needing flexible, nested data from many sources	GraphQL
High-volume calls between your own backend services	gRPC
Live updates pushed to browsers or apps	WebSockets / SignalR / SSE
Long-running work, decoupled services	Message queues (later in this track)

Many systems use several: REST for the public API, gRPC between services, SignalR for notifications.

Key takeaways

GraphQL: clients query exactly the data they need through one typed endpoint.
gRPC: compact, strongly typed, HTTP/2-based RPC — ideal between services.
WebSockets: persistent two-way connections for real-time push.
Pick per use case; REST + JSON remains the safest default for public APIs.