--- title: gRPC vs REST Is the Wrong Question · Buf | daily.dev description: The framing of gRPC vs REST as an either/or choice is challenged by presenting Connect, a protocol from Buf that lets a single server speak gRPC, gRPC-Web, and... canonical: https://daily.dev/posts/grpc-vs-rest-is-the-wrong-question-buf-xe2qehlxz twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: gRPC vs REST Is the Wrong Question · Buf | daily.dev og:description: The framing of gRPC vs REST as an either/or choice is challenged by presenting Connect, a protocol from Buf that lets a single server speak gRPC, gRPC-Web, and... og:url: https://daily.dev/posts/grpc-vs-rest-is-the-wrong-question-buf-xe2qehlxz og:image: https://api.daily.dev/og/posts/xe2qEHlXz.png og:image:alt: gRPC vs REST Is the Wrong Question · Buf og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # gRPC vs REST Is the Wrong Question · Buf **[Buf Blog](https://daily.dev/sources/buf)** · 6 min read · 109 upvotes · 4 comments ## Summary The framing of gRPC vs REST as an either/or choice is challenged by presenting Connect, a protocol from Buf that lets a single server speak gRPC, gRPC-Web, and Connect simultaneously. Standard gRPC can't be called directly from browsers because it relies on HTTP/2 trailers, and workarounds like gRPC-Web and gRPC-Gateway require extra proxies or fail the basic curl test. Connect solves this by allowing unary calls as plain HTTP with JSON POST bodies, GET requests with normal HTTP caching, and proper HTTP status codes, while still generating type-safe clients, supporting binary Protobuf, streaming (server-streaming works in browsers, client/bidi streaming stays backend-only), and schema-based breaking-change detection via buf breaking. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why can't browsers call a standard gRPC service directly? Standard gRPC relies on HTTP/2 features that browser JavaScript APIs don't expose, including trailers used to carry the response status. Because of this, browsers cannot make raw gRPC calls, which is why bridging solutions like gRPC-Web or gateway proxies such as gRPC-Gateway and Envoy were created to translate HTTP/JSON requests into gRPC calls on the backend. _daily.dev surfaces practical writeups like this for developers weighing gRPC against browser-facing API needs._ ### What happened to the official grpc-web project? The official grpc/grpc-web project effectively stalled: its own roadmap states it can no longer deliver new modern solutions, has no plans to add features, and now recommends using gRPC-Gateway instead. It still functions as a protocol spoken by other implementations like Connect, but active development of the original client library has ended. _Developers tracking the state of gRPC-Web tooling can follow ecosystem shifts like this on daily.dev._ ### How does the Connect protocol let a server support gRPC, gRPC-Web, and plain HTTP JSON without separate proxies? A Connect server speaks gRPC, gRPC-Web, and Connect on the same port from a single implementation, decoding whichever protocol a client sends before passing it to the handler. Browsers can send JSON or binary Protobuf directly to the same URL a gRPC client uses, unary calls can even use plain GET requests that support normal HTTP caching, eliminating the need for a separate gateway proxy. _daily.dev helps developers deciding between API protocol strategies compare approaches like Connect._ ## Community discussion Top comments from developers on daily.dev. **@andychiare** · 6 upvotes > “gRPC vs. REST” is the wrong question because, fundamentally, they use different paradigms. > > Of course, I’m referring to REST as the architectural paradigm originally conceived by Roy Fielding, not to the Web APIs we use every day and mistakenly call them RESTful. > > gRPC is based on the remote procedure call paradigm (everything is a procedure or function to be called), while REST is a resource-oriented paradigm (everything is a resource). Hard to to compare them effectively. **@ristotoldsep** · 3 upvotes > Browser-friendly AND passes the curl test? That’s a pretty good sales pitch. **@ahmetozel** · 0 upvotes > The browser limitation around HTTP/2 trailers is a useful reason to separate transport support from the service contract. Connect can simplify access without making all clients equally capable: server streaming in a browser is still a different operating case from bidirectional streaming between backend services. > > I would make that distinction explicit in the API compatibility tests. Run the same unary call through JSON HTTP and generated clients, then check cancellation, deadlines, and error mapping separately for each streaming mode. Schema compatibility catches structural breaks, but it... ## Similar posts on daily.dev - [gRPC-Web Failed the Web · Buf](https://daily.dev/posts/grpc-web-failed-the-web-buf-yxi6aoslo) · Buf Blog · 51 upvotes · 8 comments - [gRPC deep dive: from service definition to wire format](https://daily.dev/posts/grpc-deep-dive-from-service-definition-to-wire-format-mykdq3gjn) · Hacker News · 0 upvotes · 0 comments - [From RPC to gRPC: Understanding Remote Procedure Calls, Protocol Buffers, and Modern Distributed Systems Communication](https://daily.dev/posts/from-rpc-to-grpc-understanding-remote-procedure-calls-protocol-buffers-and-modern-distributed-sys-hdfydjpc0) · freeCodeCamp · 1 upvotes · 0 comments - [Cloudflare Workers Accept Inbound TCP, with gRPC the First Protocol on Top](https://daily.dev/posts/cloudflare-workers-accept-inbound-tcp-with-grpc-the-first-protocol-on-top-pplojcdxn) · InfoQ · 0 upvotes · 0 comments --- Tags: [#architecture](https://daily.dev/tags/architecture), [#backend](https://daily.dev/tags/backend), [#rest-api](https://daily.dev/tags/rest-api), [#grpc](https://daily.dev/tags/grpc) [View this post on daily.dev](https://daily.dev/posts/grpc-vs-rest-is-the-wrong-question-buf-xe2qehlxz) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"gRPC vs REST Is the Wrong Question · Buf","url":"https://daily.dev/posts/grpc-vs-rest-is-the-wrong-question-buf-xe2qehlxz","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/grpc-vs-rest-is-the-wrong-question-buf-xe2qehlxz"},"datePublished":"2026-09-30T15:10:05.625Z","dateModified":"2026-09-30T15:10:30.207Z","description":"The framing of gRPC vs REST as an either/or choice is challenged by presenting Connect, a protocol from Buf that lets a single server speak gRPC, gRPC-Web, and...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/38630deebaa1aed4b355c2db10acfaa2?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/38630deebaa1aed4b355c2db10acfaa2?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Buf Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Buf Blog","logo":"https://media.daily.dev/image/upload/s--2YBgo_Nm--/f_auto,q_auto/v1787469605/logos/buf?_a=BAMAMicg0","url":"https://daily.dev/sources/buf"},"commentCount":4,"discussionUrl":"https://daily.dev/posts/grpc-vs-rest-is-the-wrong-question-buf-xe2qehlxz","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":109},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":4}],"keywords":"architecture,backend,rest-api,grpc","timeRequired":"PT6M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Buf Blog","item":"https://daily.dev/sources/buf"},{"@type":"ListItem","position":3,"name":"gRPC vs REST Is the Wrong Question · Buf"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/grpc-vs-rest-is-the-wrong-question-buf-xe2qehlxz","comment":[{"@type":"Comment","text":"“gRPC vs. REST” is the wrong question because, fundamentally, they use different paradigms.\nOf course, I’m referring to REST as the architectural paradigm originally conceived by Roy Fielding, not to the Web APIs we use every day and mistakenly call them RESTful.\ngRPC is based on the remote procedure call paradigm (everything is a procedure or function to be called), while REST is a resource-oriented paradigm (everything is a resource). Hard to to compare them effectively.","datePublished":"2026-10-01T06:56:55.498Z","url":"https://daily.dev/posts/xe2qEHlXz#c-6ov4Pd2m6","author":{"@type":"Person","name":"Andrea Chiarelli","url":"https://daily.dev/andychiare","image":"https://avatars.githubusercontent.com/u/25705235?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":6}},{"@type":"Comment","text":"Browser-friendly AND passes the curl test? That’s a pretty good sales pitch.","datePublished":"2026-10-01T11:39:18.907Z","url":"https://daily.dev/posts/xe2qEHlXz#c-uNqakYZ53","author":{"@type":"Person","name":"Risto Tõldsep","url":"https://daily.dev/ristotoldsep","image":"https://lh3.googleusercontent.com/a/ACg8ocLDWc6mZn0JwNmXXw6WY0L_HJ6pegzRttooC5VgtXESHSj3MNYx=s96-c"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3}},{"@type":"Comment","text":"The browser limitation around HTTP/2 trailers is a useful reason to separate transport support from the service contract. Connect can simplify access without making all clients equally capable: server streaming in a browser is still a different operating case from bidirectional streaming between backend services.\nI would make that distinction explicit in the API compatibility tests. Run the same unary call through JSON HTTP and generated clients, then check cancellation, deadlines, and error mapping separately for each streaming mode. Schema compatibility catches structural breaks, but it will not catch a proxy buffering an entire response or a client that no longer propagates cancellation.","datePublished":"2026-10-04T16:58:32.507Z","url":"https://daily.dev/posts/xe2qEHlXz#c-wM8ah7wcN","author":{"@type":"Person","name":"Ahmet Özel","url":"https://daily.dev/ahmetozel","image":"https://avatars.githubusercontent.com/u/70992231?v=4"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/grpc-vs-rest-is-the-wrong-question-buf-xe2qehlxz#faq","mainEntity":[{"@type":"Question","name":"Why can't browsers call a standard gRPC service directly?","acceptedAnswer":{"@type":"Answer","text":"Standard gRPC relies on HTTP/2 features that browser JavaScript APIs don't expose, including trailers used to carry the response status. Because of this, browsers cannot make raw gRPC calls, which is why bridging solutions like gRPC-Web or gateway proxies such as gRPC-Gateway and Envoy were created to translate HTTP/JSON requests into gRPC calls on the backend. daily.dev surfaces practical writeups like this for developers weighing gRPC against browser-facing API needs."}},{"@type":"Question","name":"What happened to the official grpc-web project?","acceptedAnswer":{"@type":"Answer","text":"The official grpc/grpc-web project effectively stalled: its own roadmap states it can no longer deliver new modern solutions, has no plans to add features, and now recommends using gRPC-Gateway instead. It still functions as a protocol spoken by other implementations like Connect, but active development of the original client library has ended. Developers tracking the state of gRPC-Web tooling can follow ecosystem shifts like this on daily.dev."}},{"@type":"Question","name":"How does the Connect protocol let a server support gRPC, gRPC-Web, and plain HTTP JSON without separate proxies?","acceptedAnswer":{"@type":"Answer","text":"A Connect server speaks gRPC, gRPC-Web, and Connect on the same port from a single implementation, decoding whichever protocol a client sends before passing it to the handler. Browsers can send JSON or binary Protobuf directly to the same URL a gRPC client uses, unary calls can even use plain GET requests that support normal HTTP caching, eliminating the need for a separate gateway proxy. daily.dev helps developers deciding between API protocol strategies compare approaches like Connect."}}]} ```