REST, gRPC, SignalR and GraphQL for .NET developers
summary
Compares four concrete choices and gives an opinionated decision tree: use gRPC via Protocol Buffers and HTTP/2 for internal service-to-service APIs when teams can coordinate schema updates (binary payloads, HTTP/2 performance, bidirectional streaming, multi-language stubs); use GraphQL with Hot Chocolate or Apollo when multiple clients need different shapes of data and you want clients to request only needed fields (adds subscriptions and caching complexity); use SignalR over WebSockets for server-to-client RPC when a .NET backend-for-frontend needs near‑real‑time pushes; fallback to REST/ASP.NET Web API when none of the above requirements exist.
AI-written summary · about
chapters (11)
- 0:00Introduction and motivation
- 3:23Overview of API options
- 7:24Debunking REST dominance
- 7:36Understanding REST principles
- 19:54Introduction to gRPC
- 24:53Challenges with data flexibility
- 25:08Introduction to GraphQL
- 31:13Real-time communication needs
- 34:35Transitioning to decision tree
- 38:02Conclusion and community
- 38:46Floor open for questions
related talks
59mGraphQL, gRPC or REST? Resolving the API Developer's Dilemma
01h 15mREST, GraphQL, and gRPC: A Comparison
50mREST, gRPC, GraphQL, Webhooks: When to Use Each?
46mREST API vs gRPC, which one should you use in breaking a monolith
48mChoosing the Right Technology for your API
26mRest, GraphQL & gRPC
55mEmbracing gRPC in .NET
01h 09mBuild a Highly Performant Interservice Communication with gRPC for ASP NET Core