16 ms·

Connect-Web: TypeScript library for calling RPC servers from web browsers

221 points by emidoots 4y ago

bjt2n3904 4y ago
"It's time for..." Good grief. Pretentious much?
- dboreham 4y ago
  Also a reliable indicator that it was never time.
hmillison 4y ago
I have used protobufs and grpc on the web before. Maybe this project is the magic bullet that makes it easy to do, but in the past that typescript support from Google and 3rd parties (improbable eng) was lacking and there was little interest in making simple changes to make it easier to use. On top of that, the increase in JS shipped to user's due to the size of the generated protobuf objects was unacceptable for anything that cares about keeping their bundle size manageable. Have you done anything to address this issue?
- rockemsockem 4y ago
  The article specifically mentions that bundle sizes for grpc packages in the past were unacceptable and that they've made big improvements.
  - mf192 4y ago
    Ye, fwiw there is an example code size comparison here: https://github.com/bufbuild/connect-web/blob/main/packages/connect-web-bench/README.md https://github.com/bufbuild/connect-web/blob/main/packages/c... I'm sure someone will chime in on the implementation details, but hopefully others can give it a try with their projects!
  - hmillison 4y ago
    That's great news! I missed that in my initial skim of the article.
- timostamm 4y ago
  Not sure if it is a magic bullet, but it was definitely written by TypeScript developers, for TypeScript developers. The generated TypeScript code is already pretty minimal because all serialization ops are implemented with reflection instead of generated code (which is only marginally slower than generated code in JS). But you can also switch to generating JavaScript + TypeScript declaration files, which is truly minimal: JavaScript is an entire dynamic language, so we actually only generated a small snippet of metadata in the .js output, and create a class at run time with a function call. The generated typings (.d.ts) give you type safety, autocompletion in the IDE, and so on. You can see the output here: https://github.com/bufbuild/protobuf-es/blob/main/packages/protobuf-test/src/gen/js/extra/example_pb.js https://github.com/bufbuild/protobuf-es/blob/main/packages/p...
rektide 4y ago
If the browser folk had ever made HTTP Push available for use to the web page, such that actual grpc could run, I'd agree. gRPC/the web are at an impasse versus browsermakers who are resistant to new capabilities & who gave up on push as unsuccessful after never letting us try. Here's a good recent (4 year old) issue; it links back to much older issues. https://github.com/whatwg/fetch/issues/607 https://github.com/whatwg/fetch/issues/607 The rest of the protobuf world has gotten so much better. But the grpc on the web hacks feel bad. The awful option of running http3-over-webtransport-over-http3 is becoming alluring given the lack of browser care for the basics, and that's terrifying (it means the page loading & running it's own page/userland http3 stack). But there doesn't seem to be room for progress & innovation & even basic continuity/ways forward, with HTTP Push getting shoved out the airplane door. The work here to build yet another protocol that is gRPC like to workaround limitations is heroic. It's unfortunate that protocol development in general is hamstrung by these awkward longstanding limitations in the browser.
- akshayshah 4y ago
  From my limited perspective, it'd certainly be nice if browsers exposed more of HTTP. I also appreciate that the web platform is far larger, and far more backward-compatible, than any code I've ever even considered writing. If browser makers are slow to expose new protocol features, that's a cost I'm happy to pay. At least as I understand it, HTTP Push isn't the problem. The key problem is that browsers don't want to expose HTTP trailers. I understand their reluctance - even putting aside the security concerns, it's a huge semantic change. Many HTTP response headers, like etags, are typically computed by buffering the response, running some compute, then sending headers and the buffered body. All of those would, presumably, now need to also be sendable as trailers. What if the server sends both an etag header and trailer, and they don't match? The rabbit hole goes pretty far. Here's the Chromium issue where the gRPC and Chrome teams debate the issue: https://bugs.chromium.org/p/chromium/issues/detail?id=691599 https://bugs.chromium.org/p/chromium/issues/detail?id=691599. There's also a series of whatwg issues about exposing trailers in the fetch API: https://github.com/whatwg/fetch/issues/34 https://github.com/whatwg/fetch/issues/34. For a protocol that sits above L7, the gRPC HTTP/2 protocol is liberal about diving past the semantics outlined in RFC 9110 and specifying transport-level details. (As an example, trailers-only responses must be sent in a _single_ HTTP/2 headers frame with the EOS bit set.) That degree of specificity unlocks some performance gains, but it makes it near-impossible to speak this protocol using an existing HTTP library - a traditional strength of building on top of L7. For broad adoption in a _lot_ of environments, gRPC-Web (and Connect) are IMO much better protocols.
fizx 4y ago
There seems to be two groups of protobuf libraries for HTTP 1.1, the ones that want to make it look like binary+HTTP/2 grpc (grpc-web, grpc-gateway), and the ones that make it look like idiomatic web tech (twirp). I'm excited to see more ideas in the second category.
- mf192 4y ago
  Curious, do you see connect-web falling into the former or the latter group?
- jrockway 4y ago
  grpc-gateway is actually in the second class. It allows you to annotate your protobuf so as to create a JSON + HTTP method based API (people call this "REST") that is translated to gRPC for your actual backend. (gRPC/Web is protobufs over HTTP/1.1. Different than strict HTTP/1.1 transcoding, though, which is also possible for gRPC to do.) I think grpc-gateway is absolutely what 99% of users want to do. You can generate client stubs (it will even output an OpenAPI spec) like you can do for gRPC + protos, but it's all HTTP/1.1 + JSON over the wire, so if you really want to hand craft curl requests, you can. (But with an OpenAPI spec, you'll really like just plugging it into some GUI tool to make these one-off requests. Even curl diehards like myself.) grpc-gateway is also up front about not supporting things browsers can't do, like bidirectional streaming. gRPC/Web always disappointed me on that front; "coming soon" for years. In the past, I used grpc-gateway (in process, some minor downsides compared to running the gateway as a separate process) + gRPC for my service's internal admin API. It was very few lines of code whenever you wanted to add a new endpoint, and because of the OpenAPI spec, it became available for use in our admin GUI as soon as you pushed the new server code. If someone wanted to add a new endpoint, there was basically no tedium, edit the proto, "go generate ...", implement the generated interface with your actual functionality, push to production. We embedded the generated OpenAPI spec in the doc, so you could just point at app.example.com/OpenAPI.json and clients would auto-update to see your new endpoint.) I actually converted in-place a hand-coded REST API; all the requests and responses and endpoints stayed the same (thanks to the power of the grpc-gateway annotations), but I deleted all the code in every handler that did the marshaling and unmarshaling. The result was something that was very easy to add to and maintain. I liked it a lot and would do it again without hesitation. (We used Retool as the GUI. Not sure I'd recommend it, but it worked fine. I've seen some HN posts about open source alternatives, those look awesome.) I have also written several apps that use gRPC/Web. I didn't find the experience bad, but the Javascript bundle size is huge, so I never felt great about it. grpc-gateway should be the first thing you look at, your server code will be simple, and your client code will be small. And hey, if you have non-web clients, plain gRPC is great too.
halfmatthalfcat 4y ago
gRPC-web just isn't there yet but appreciate the work in the space. There's also an issue with a proliferation of transpilation (protoc) projects: - grpc-web (the standard binary protocol) with the optional TS emit - grpc-web-text with the optional TS emit - gprc-ts - ts-proto Which to use when, why and the issues with interop between backend/frontend server implementations. Also the streaming story isn't great. Also the need for Envoy as another piece of infra to manage isn't great either.
- mf192 4y ago
  You're right, gRPC-web isn't there and likely won't get there. That's why we need something like connect-web. - no proxies - smaller bundle size - idiomatic TS code in both runtime and generated code - streaming - ... and more
- lucas_codes 4y ago
  What is grpc-web-text?
  - akshayshah 4y ago
    It's a variant of the gRPC-Web format that base64-encodes the request and response bodies. It was designed for very old browsers that don't support the fetch API and can't send/receive binary data. All those browsers have been end-of-lifed, and they now represent a tiny fraction of web users. In short, it's a relic of a bygone age.
theogravity 4y ago
I would really emphasize the no proxy required part in the intro of this post. To me its one of the huge factors for not using grpc from the web.
- rektide 4y ago
  But your services have to support the Connect protocol. You can also ship services that support gRPC-Web directly too & run without a proxy. This is definitely a step up, nicely convenient. But also, it has downsides too. gRPC is incredibly well supported by a huge number of observability tools and service-layers/service-mesh systems. Few have support for gRPC-Web. Which if any have support for Connect-Web? In general, it's just massively sad that the browser never got around to making HTTP Push useful for protocols. gRPC should have been positioned to do great things, was a very common-sense overlay atop HTTP2 that provided just a little more semantics to say how things ought work. It triangulated nicely on where we were going, at it's inception, back in 2014/2015. But the browser basically never evolved, never gave developers access to do the good stuff we thought we'd start to have access to. I still see brand new specs that shout out to the Low Level Extensibility Manifesto[1], but for some reason, in terms of the most base layer of the web, HTTP, this simple guidance has been roundly ignored & the capabilities were never delivered. So gRPC has been stuck with a pretty ok protocol, & frustratingly discompatible browser. [1] https://github.com/extensibleweb/manifesto https://github.com/extensibleweb/manifesto
  - sjroot 4y ago
    Yeah this is the deal breaker for me as well. This smells like an embrace-extend-extinguish campaign frankly? 1. Embrace gRPC and protobuf 2. Extend with Connect, get everyone using this in their APIs and web apps 3. Drift away from established gRPC and/or protobuf standards, build platforms/business around this and trap as many folks as possible As silly as it may seem, one thing that really sends this signal for me is the nice trademark symbol on the Buf name. their intention for all of this stuff is to build a business.
    - akshayshah 4y ago
newaccount2021 4y ago
deleted 4y ago
[deleted]
89vision 4y ago
I once worked on a home built browser grpc implementation where the protobufs were serialized over the wire in base64. It certainly had it's kinks to work out, but sharing/generating the service definitions and models from the same protobuf markup between backend and frontend was really nice.
- nine_k 4y ago
  Doesn't OpenAPI (née Swagger) give you the same for plain HTTP + JSON?
  - AtNightWeCode 4y ago
    Yes, you can even generate models from JSON directly. Then there is JSON Schema and other schema first options that mostly no one uses anymore.
  - 89vision 4y ago
    yeah, I've done both, but I far prefer writing protobuf markup than swagger. YMMV
- miohtama 4y ago
  I was working with Cosmos nodes in a hackathon and they did RPC where one had Protobufs embedded as base64 encoded within JSON.
lotw_dot_site 4y ago
No demo. I was wondering what kinds of things I could be doing here that I couldn't do before (with websockets, webrtc, etc) but demo.connect.build just redirects to connect.build. I'd only known of "Protocol Buffers" as something that was internal to Google, but never knew exactly to what end.
- lotw_dot_site 4y ago
  Nevermind, I see the demo is the Eliza widget on the main page. So, I can do Eliza with it then... I'll keep that in mind for the next time that I need to get an Eliza widget working ;)
- akshayshah 4y ago
  The little demo application is on the connect.build homepage and on https://connect.build/demo https://connect.build/demo. I completely forgot to fix the redirect from demo.connect.build to point to the actual demo page - thank you for reminding me :) Protocol Buffers are just a schema language. They're spiritually akin to OpenAPI, Thrift, Avro, and a bunch of other contract-type things. They're _also_ a binary serialization format that's usually faster and more compact than JSON. The intention is to use Protocol Buffers as a language-independent way of describing data bags and network APIs, and then use that schema/contract to generate code in the language you actually work in. It's not that you _can't_ do that with websockets, webrtc, or just RESTful HTTP/1.1 - it's that you shouldn't _need_ to. The hand-written code to define the same data bag classes/interfaces/structs/etc in multiple languages, then wire them up to the same HTTP boilerplate isn't difficult or interesting, it's just toil. For all the times you're just calling an API, Protobuf lets you get on with the interesting work and skip the boilerplate. Ideally, things work well even if you're writing client code in a language that the server team doesn't have any expertise in. If you're doing something unusual and need webrtc/websockets/etc, go for it!
boardwaalk 4y ago
It looks like the Connect protocol supports client streaming, which gRPC-Web doesn’t, but the only way for a server to speak connect-web is to write it in Go and use their libraries? What about servers in other languages? Are there any plans for f.e. Envoy support for going from Connect the frontend to gRPC on the backend? Like gRPC-Web to gRPC?
- akshayshah 4y ago
  The gRPC-Web _protocol_ supports streaming - it supports everything that standard gRPC does.* The client libraries that operate in web browsers don't support client streaming, because every major browser currently buffers request bodies. Right now, you're correct - the easiest way for another server to speak the Connect protocol is to use connect-go. We're planning to support more backend languages soon: Node.js is up next, with the JVM maybe afterwards. We'd also love to contribute (time, code, review, whatever) to any other backend implementations - the protocol is not that complex. File an issue on one of our projects or ping us in our Slack, it'll probably be an easy sell. Envoy support is complicated. The honest truth is that we haven't looked into it all that much because it feels rude - Envoy's architecture requires first-party plugins to live in the main repo, and it feels impolite to attempt a C++ code dump for our new project. Maybe once Connect takes the world by storm :) Even if we did do that, a Connect-to-gRPC translation layer would only work for binary payloads - converting JSON to binary protobuf requires the schemas, and redeploying proxies every time the schema changes is an operational nightmare. * Worth noting that gRPC-Web doesn't really have a specification. There's a narrative description of how gRPC-Web differs from standard gRPC, but they specifically mention that the protocol is defined by the reference implementation in Envoy.
  - boardwaalk 4y ago
    Thank you for the detailed reply! Random thoughts: I personally would not mind requiring Protobuf payloads so the proxy portion can stay dumb — keeping proxies up to date sounds no fun. Losing inspectability (not having JSON) is a minus but not a deal breaker. Requiring servers to use a new library is a big lift for people, and hard to sell if what you have works. Having a proxy you can drop in the meantime, while getting client streaming at the same time, seems nice. In any case, having the shiny Typescript friendly libraries that can easily switch between gRPC-Web and Connect is nice, so thanks for that. For what it’s worth, our servers are C++ and use Arrow Flight which why I’m even interested in client streaming at all (its DoPut method has a streaming argument). My current solution is to add a regular gRPC method that behaves similarly to DoPut but is a unary call for browser clients. Not terrible, but it’d be nice to not have to do that. I may well take you up on filing an issue/pinging y’all on Slack.
masukomi 4y ago
protobuffers are no end of pain for me at work. Yes, the guarantee of no breaking changes in an API is wonderful. Everything else sucks. Not being able to use JSON to test your api? sucks. Having to convert the changed .proto files to a new library for your language (gem for ruby in my case) and then have your system use that instead of the latest release (because you haven't tested it yet) sucks. A terrible ruby library written by people who were obviously not ruby devs (it makes FooServiceService classes for example)? sucks. hoop-jumping to force a breaking change in something you thought was good, but isn't and hasn't been released yet? Sucks horribly degraded iteration loops on new functionality? sucks not being able to host it anywhere that doesn't support HTTP2 (Heroku)? sucks Unless you're working on something at google scale and the performance difference and bandwidth savings are actually noticeable RUN FOR THE HILLS. Protobuffers will bring you nothing but pain.
- francislavoie 4y ago
  Seconded, for PHP. It's such a nightmare to work with.
- aseipp 4y ago
  Also, even if you do want to have some kind of binary-ized transport with a strict type-checked schema and compilers for multiple languages -- ultimately a noble goal, I think -- there are much better options available, design and technology wise. Cap'n Proto is wonderful with a very strong foundational design and good implementation, it's major drawback being a relatively sparse set of working languages, and a lack of tooling. But then again the quality of 3rd party Protocol Buffers libraries has always been a complete gamble (test it until you break it, fork it and patch it to make due), and as you note the tools aren't all there for gRPC either. So in general I completely agree. If you are exposing a Web API to consumers -- just keep doing RPC, with HTTP APIs, with normal HTTP verbs and JSON bodies or whatever. Even GraphQL, despite having a lot of pitfalls, and being "hip and fancy", still just works normally with cURL/JSON at the end of the day because it still works on these principles. And that matters a lot for consumers of Web APIs where some of your users might literally be bash scripts.
- franciscop 4y ago
vosper 4y ago
If you've got Typescript on front-end and back-end then I'd recommend looking at tRPC. The schema is your types, which might often just be the type of your DB response, leading to low-code but fully type-safe coding. https://trpc.io/ https://trpc.io/
- sgammon 4y ago
  pretty useless as an RPC layer if it imposes language restrictions…
  - bluepizza 4y ago
    Why?
    - sgammon 4y ago
      Because the point of an RPC layer is to communicate between pieces of software, and you often have no guarantee of control over the languages they are written in.
      - bluepizza 4y ago
        That’s true for microservices environments in modern companies. But a lot of traditional companies have languages and versions locked and mandated. The point of RPC layer is just to remotely call a procedure.
- akshayshah 4y ago
  tRPC is awesome - if you're writing full-stack TypeScript and don't care about other languages, it's very convenient. Protobuf might be a more appealing choice if you want to support clients in other languages, or if you're interested in getting a bit more value out of your contract language (e.g., breaking change detection).
- junon 4y ago
  Or just use AJV which has the ability to statically represent JSON Schemas as full-fledged types, so that the schemas themselves become the authoritative IDL, via the new JSONDataType in AJV@7.
fyrn- 4y ago
Cap'nProto Is so much better. Really a lot are, but Cap'nProto is main by the original protobuff dev so his description of why he made it is relevant. I use protobuff everday at work and honestly the generated code is incredibly awful conpared to pretty much any alternative. We're way to bought in to switch now though sadly.
- melony 4y ago
  There aren't enough good cap'n proto code generators (compared to protobuffs/flatbuffs). It is not viable unless your stack is mainly C++.
  - junon 4y ago
    I use it in Rust just fine, FWIW.
- kentonv 4y ago
  Hi. That's me. I'm glad you like it. Unfortunately, melony is right: I've only really been able to focus on the C++ implementation of Cap'n Proto. Some of the others are solid (e.g. Go, Rust), but many are sort of half-baked weekend projects of random people, which were later abandoned. As a result it's tough for me to recommend Cap'n Proto in polyglot environments. Maybe someday I'll be able to find the time / resources to build out the ecosystem more fully. Great tooling is really important for any of this to work. I'm also an investor in Buf FWIW. I think what they're doing is pretty cool.
  - junon 4y ago
    Hi, I like capnproto as well, thanks for making it. :)
- djbusby 4y ago
  Which are better? I don't even have a big list of xRPC/xBuf tool - only know of two (now three). Can you point to others?
mosdl 4y ago
Has anyone used their protobuf-es library? Seems interesting and better than the other libraries from a quick glance. I wonder if there are bazel rules for it.
- akshayshah 4y ago
  Probably not - we wrote it alongside connect-web, so it also launched very recently :) We do think it's the best option for protobuf code generation in TypeScript, though. It comes from quite a few years of experience with proto & TS: the primary author is also the author and maintainer of protobuf-ts, and we had the author of ts-proto review it and give us a thumbs-up before launch. There _could_ be Bazel rules for it - we certainly write enough other Bazel integrations. Mind filing an issue on https://github.com/bufbuild/protobuf-es https://github.com/bufbuild/protobuf-es?
  - mosdl 4y ago
    Sure, opened an issue.
sgammon 4y ago
I am so incredibly excited about this. Buf is an amazing tool that every proto developer should know Great work Buf team
AtNightWeCode 4y ago
This is not the first attempt to run gRPC from web. It is still a bad idea since it does not play nice with common web infra. I don’t understand what one even tries to accomplish with this.
- biggestlou 4y ago
  I strongly suggest that you read the post to see why this project is different and specifically intended to place nicely with common web infra.
  - hamandcheese 4y ago
    The post says it is a post-only API. I’m not sure if thats to a single URI, like graphql, or if the URI is different depending on the RPC call in use. But either way, it sounds like cacheability might not be great, which is also an issue with graphql. That said, it’s definitely a step in the right direction, and I personally have never written an API where I even wanted the results to be cached.
    - bufbuild 4y ago
      The URI is per-RPC, specifically at /service/method, if that helps. On cacheability, do check out https://connect.build/docs/protocol#future-extensions https://connect.build/docs/protocol#future-extensions - it’s something we continue to put thought into to make sure we get it right.
  - AtNightWeCode 4y ago
    I understand that is does not come with a proxy which is a leap forward. GETs are often optimized in various ways and gRPC is designed for reusing channels.
- upbeat_general 4y ago
  Perhaps unifying tooling/infra if you’re already using gRPC for your services.
- 4y ago
FpUser 4y ago
Been using post only JSON based RPC of my own cooking for ages. Worked well for me and my clients.
yandie 4y ago
But then we have to use yet another protocol?
- timostamm 4y ago
  If you want to be able to see data in the browsers network inspector, you do. If you are already serving gRPC-web, you can use the gRPC-web transport in connect-web, it supports both protocols. It doesn't support plain gRPC because web browsers do not expose trailers, and gRPC uses them extensively.
time4tea 4y ago
I just love how a zero byte protobuf message deserialises into a valid struct. Very reassuring.
- net_ 4y ago
  In the other direction, the "all fields at default value serializes as size 0 message that you can't send" behavior has been an unending annoyance since switching to proto3.
- jeffbee 4y ago
  That's the example I always use for the people who say that protocol buffers are "type-safe" which they emphatically are not. Any empty buffer will successfully decode as any message that has only optional fields!
  - dathinab 4y ago
    the idea of protobuf is "init to default value and then incremental merge message fragments". Which is even more crazy then missing parts have default value, when you consider how that behaves in some cases of mismatching schemas (it also can introduce annoying limitations when trying to create idiomatic libraries in some languages, especially such with "type-safety"). And then add in some of the "automatic type conversions it does". And to top if of some edge cases tend to very often diverge in implementations of different languages, no matter what the original intention was. And the result is uh, just uh, very very uh. I understand why google uses them, it fits them. It probably a good idea given google scale problems, company and team structure and "skill level" of each member. But that doesn't mean it's a good fit for everyone.
    - jeffbee 4y ago
      To be fair to protobuf, its own docs make no claims about "safe". That is projected upon it by people who do not understand it.
      - xyzzy_plugh 4y ago
victorvosk 4y ago
or... https://github.com/t3-oss/create-t3-app https://github.com/t3-oss/create-t3-app
dathinab 4y ago
But protobuf isn't grate, especially proto v3 is tuned exactly for googles needs, tools and approaches. But googles needs, tools and approaches are not fitting for most smaller companies. And gRPC adds a bunch of additional complexity and failure modes, sure it's worth considering especially for larger projects. But a lot of projects get away just fine with a surprising small number of endpoints.
- akshayshah 4y ago
  For the most part, we agree! Protobuf isn't perfect. gRPC is _definitely_ optimized for megacorporation-sized problems. No matter who you are, though, it's not fun to hand-write boilerplate data types and fetch calls or quibble over which parameters should go in the path and which should be query params. Even when you're actually sending JSON on the wire and using regular HTTP/1.1 POSTs, Protobuf and connect-web make it easy to skip right to the interesting part of your code.
  - 0x001D 4y ago
    I'm curious how flexible one is if proto3 is given as it is from a schema perspective, where a true schema/constrains language like CUE could be a vehicle to define schemas and then transform that to anything needed, like protobufs or even stubs serializing on the wire.
maerF0x0 4y ago
For those griping about using JSON manually with their APIs ... This tool is a big help for working with GRPC (at least from cli) https://github.com/fullstorydev/grpcurl https://github.com/fullstorydev/grpcurl
- FridgeSeal 4y ago
  There’s also BloomRPC, which is like Postman/Insomnia for GRPC: https://github.com/bloomrpc/bloomrpc https://github.com/bloomrpc/bloomrpc
  - bufbuild 4y ago
    And there’s Buf Studio :-) https://buf.build/blog/buf-studio https://buf.build/blog/buf-studio https://studio.buf.build https://studio.buf.build
  - nsxwolf 4y ago
    Insomnia and Postman also support gRPC now as well. Lots of choices.
    - FridgeSeal 4y ago
      I found insomnia's grpc support a bit lacking - notably, it won't refresh the grpc definitions from disk without reloading your whole environment, and doesn't auto-populate the window with the keys. The latter is a more minor concern, but when you have larger protos it does become annoying.
rdevsrex 4y ago
Unless you are already working with them, I'd much prefer using tRPC.
meisel 4y ago
I generally find Protobuf the serialization format to have no benefits over JSON. Although Protobuf is often thought of as being faster to process and more compact, the reality is that it's usually not (at least as long as you're not working in a systems language like Rust or C++). It's not much faster than JSON to process because in the context of higher-level languages, the time to create usable objects out of the parsed input (which is independent of the serialized data they came from) is usually far larger than the time to parse the payload. And as for being more compact, if you gzip a Protobuf payload and its JSON equivalent, IME they end up being pretty close in size (sometimes the JSON version is actually smaller).
- mkoryak 4y ago
  What about the benefit of being able to represent data types like Date, double vs float vs byte etc ?
  - klysm 4y ago
    ISO8601 gets you pretty far with dates and you can always quote your numbers - most serialization frameworks support that
- zeroxfe 4y ago
  We migrated many of our critical protocols from JSON to protobuf, and the experience has been very positive. As your system gets bigger, and your teams get bigger, the value of a typed schema has a multiplicative effect on both reliability and productivity. In addition, a lot of basic features around managing transport, like load balancing, health checking, deadlines, etc. come out of the box. IMO, performance is the least of the reasons to use protobufs. And if you're working on simple systems in small teams (or solo), then JSON is a better fit (because it's simpler to understand, debug, and iterate with.) gRPC is definitely not a one-size-fits-all.
  - nwah1 4y ago
    Swagger/OpenAPI offers a typed API in JSON (along with generated clients just like gRPC). The complaints about protobuf as a serialization format remain valid, and you don't need it to have types. Also the reability of JSON in-transit is another factor to consider.
upbeat_general 4y ago
My biggest gripes with Protobufs is the language integrations. Why do I need to convert and typecheck back and forth between the proto object and the native dataclass. This was the situation in kotlin (and I believe Java) as of about a year ago though I hope it’s changed by now. We had to have several hundred lines of totally unnecessary manual type checking to validate input/output when that should be a major strength of protobufs.
denkmoon 4y ago
Back in my day we had a language for transferring data between systems in a human readable format and it even has typed schemas, and provided you're not reinventing the wheel, it's easy to work with programmatically too. XML is the language of the gods.
- sagarm 4y ago
  XML is inefficient to read and write by both computers and humans; might as well use JSON as your serialization format, it's at least more human readable.
  - denkmoon 4y ago
    Use JSON and you lose type information, schemas, and relationships. Of course you can add all that back to JSON as many people have done in various ad-hoc ways. JSON is inferior to XML in every way except "I don't want to type angle brackets and closing tags". I encounter a lot of people stating your position, that reading JSON is faster than reading XML, for a human. I cannot speak to the subjective experience of anyone but myself of course, but IMO that's a load of bunk. Spent most of my career looking at both XML and JSON, and the only time I ever have a problem is when it's not formatted/indented. We have tools for this, of course. Yet to encounter a situation where the performance of the XML parser was a limiting factor in the system I am working on. RapidXML and RapidJSON are both insanely fast if you use them as intended. If you are encountering performance issues from parsing XML you almost certainly want to move to a binary format anyway.
    - sagarm 4y ago
      I don't want to type or parse duplicate tags and angle brackets. It's nonsense for a human readable format. I work on low latency distributed systems where performance does matter. We use proto wire format mostly. Proto has its own human readable text format that I prefer because it's more convenient than JSON (no commas, unquoted keys), but I'd pick JSON over XML any day.
- 8n4vidtmkvmk 4y ago
raggi 4y ago
Are they using real binary protos yet, or is that still only a third party game? Years ago the dcodeio libs were much better than stuff Google was shipping for the web.
CMCDragonkai 4y ago
We had major problems with integrating grpc into electron and browser extensions so making something like grpc work on the web is essential. However for a decentralised application, expecting users to deploy a separate proxy is unacceptable. So we were planning to switch back to json RPC and build our own streaming system based off vscode's json RPC. Does this new connect protocol expect to support all streaming mechanisms client streaming, server streaming and bidirectional?
- bufbuild 4y ago
  It already does! The connect protocol supports all streaming mechanisms. The beauty of the Connect ecosystem is that no proxies are required - the Connect protocol works just as well from the browser as it does on the backend.
lucas_codes 4y ago
I'm rather a fan of using gRPC in a stack. It has its cons, but you get a generated client/server that is type-safe, even across different languages. Would love to hear alternatives which do the same thing. I know one possibility is OpenAPI specs generated from Django Rest Framework.
- jahewson 4y ago
  GraphQL has great tooling for this kind of thing and its web-friendly by default.
istillwritecode 4y ago
Typescript: uh no.
grosskur 4y ago
Congrats on the launch! It's great to see more innovation and choice in the protobuf/gRPC space. Definitely planning to try this out. For personal projects, I typically have a single Go binary that serves (1) gRPC, (2) grpc-web (using the Improbable library), and (3) gprc-gateway. Along with protobuf-ts for the client, IMO it's quite a pleasant stack. Glad to see timostamm involved in protobuf-es :) I'm curious: Can you say more about why you ported the code generator from Go to TypeScript (https://github.com/bufbuild/connect-web/commit/8002c2696aad0b6125050202db6341ba2178c5f7 https://github.com/bufbuild/connect-web/commit/8002c2696aad0...)? Was it is easier to generate code this way, or did it just get too unwieldy to package Go binaries in NPM modules?
- akshayshah 4y ago
  Timo is amazing, and we wouldn't have been able to build any of this without him :) We ported the code generators to TypeScript because - as you guessed - it was a bit of a pain to package them for NPM. We also felt that it would be more approachable for TypeScript developers to read, which we hoped would contribute to a sense that all of this isn't actually all that complex. We were a bit worried that performance might be perceivably worse, but the difference wasn't significant.
- lf-non 4y ago
  Improbable's grpc-web [1] works pretty well. I have been using it along with their new websocket transport for about two months and as an RPC layer its great. However I do miss being able to inspect the traffic in devtools, and the TS sdk is still not ESM friendly and requires jumping through hoops to get working with vite. So we ended up bundling it separately through esbuild (along with other google protobuf deps etc.) to a large single file ESM module that other projects can easily consume. Buf seems to be a solution that handles all of this better. Very excited to try this out. [1] https://github.com/improbable-eng/grpc-web https://github.com/improbable-eng/grpc-web
jitl 4y ago
I’m interested in these “gRPC but we care about devs outside of Google” kind of libraries! I see you’re working on generating idiomatic Typescript from Proto3 - but have you thought about generating Proto3 from Typescript? At Notion we have 1000s of lines of TS types and many TB of JSON stored in those shapes already. Rewriting all that to Protobuf by hand is kinda a non-starter. So we need to go the other direction at least initially. I started on a Typescript type -> Proto3 compiler that’s very much still in the “toy” stage. I’m also working on compiling Typescript typed to Thrift, JSOMSchema and Python; I plan to experiment with Kotlin as well after the Proto3 target is a little less janky. My work in progres branch is here, in case this is useful or you want to collaborate! Proto3 compiler: https://github.com/justjake/ts-simple-type/blob/jake--compilers-as-features/src/compile-to/proto3.ts https://github.com/justjake/ts-simple-type/blob/jake--compil... Example input and output: https://github.com/justjake/ts-simple-type/blob/jake--compilers-as-features/test/snapshots/compiler.spec.ts.md#compile-toproto3-compile-testts-to-proto3 https://github.com/justjake/ts-simple-type/blob/jake--compil...
aabbcc1241 4y ago
Protobuf may make sense for static type language, but the DX for dynamic type language like javascript and python is suboptimal. If you really need binary encoding to save some bandwidth, msgpack maybe good enough.
leshenka 4y ago
https://archive.ph/4ou6j https://archive.ph/4ou6j just in case it returns 403
est 4y ago
An example of protobuf working on websites is play.google.com And it sucks balls.
mtoohig 4y ago
H

221 points by emidoots 4y ago

bjt2n3904 4y ago

"It's time for..." Good grief. Pretentious much?

dboreham 4y ago
Also a reliable indicator that it was never time.

hmillison 4y ago

I have used protobufs and grpc on the web before. Maybe this project is the magic bullet that makes it easy to do, but in the past that typescript support from Google and 3rd parties (improbable eng) was lacking and there was little interest in making simple changes to make it easier to use. On top of that, the increase in JS shipped to user's due to the size of the generated protobuf objects was unacceptable for anything that cares about keeping their bundle size manageable. Have you done anything to address this issue?

rockemsockem 4y ago
The article specifically mentions that bundle sizes for grpc packages in the past were unacceptable and that they've made big improvements.
- mf192 4y ago
  Ye, fwiw there is an example code size comparison here: https://github.com/bufbuild/connect-web/blob/main/packages/connect-web-bench/README.md https://github.com/bufbuild/connect-web/blob/main/packages/c... I'm sure someone will chime in on the implementation details, but hopefully others can give it a try with their projects!
- hmillison 4y ago
  That's great news! I missed that in my initial skim of the article.
timostamm 4y ago
Not sure if it is a magic bullet, but it was definitely written by TypeScript developers, for TypeScript developers. The generated TypeScript code is already pretty minimal because all serialization ops are implemented with reflection instead of generated code (which is only marginally slower than generated code in JS). But you can also switch to generating JavaScript + TypeScript declaration files, which is truly minimal: JavaScript is an entire dynamic language, so we actually only generated a small snippet of metadata in the .js output, and create a class at run time with a function call. The generated typings (.d.ts) give you type safety, autocompletion in the IDE, and so on. You can see the output here: https://github.com/bufbuild/protobuf-es/blob/main/packages/protobuf-test/src/gen/js/extra/example_pb.js https://github.com/bufbuild/protobuf-es/blob/main/packages/p...

rektide 4y ago

If the browser folk had ever made HTTP Push available for use to the web page, such that actual grpc could run, I'd agree. gRPC/the web are at an impasse versus browsermakers who are resistant to new capabilities & who gave up on push as unsuccessful after never letting us try. Here's a good recent (4 year old) issue; it links back to much older issues. https://github.com/whatwg/fetch/issues/607 https://github.com/whatwg/fetch/issues/607 The rest of the protobuf world has gotten so much better. But the grpc on the web hacks feel bad. The awful option of running http3-over-webtransport-over-http3 is becoming alluring given the lack of browser care for the basics, and that's terrifying (it means the page loading & running it's own page/userland http3 stack). But there doesn't seem to be room for progress & innovation & even basic continuity/ways forward, with HTTP Push getting shoved out the airplane door. The work here to build yet another protocol that is gRPC like to workaround limitations is heroic. It's unfortunate that protocol development in general is hamstrung by these awkward longstanding limitations in the browser.

akshayshah 4y ago
From my limited perspective, it'd certainly be nice if browsers exposed more of HTTP. I also appreciate that the web platform is far larger, and far more backward-compatible, than any code I've ever even considered writing. If browser makers are slow to expose new protocol features, that's a cost I'm happy to pay. At least as I understand it, HTTP Push isn't the problem. The key problem is that browsers don't want to expose HTTP trailers. I understand their reluctance - even putting aside the security concerns, it's a huge semantic change. Many HTTP response headers, like etags, are typically computed by buffering the response, running some compute, then sending headers and the buffered body. All of those would, presumably, now need to also be sendable as trailers. What if the server sends both an etag header and trailer, and they don't match? The rabbit hole goes pretty far. Here's the Chromium issue where the gRPC and Chrome teams debate the issue: https://bugs.chromium.org/p/chromium/issues/detail?id=691599 https://bugs.chromium.org/p/chromium/issues/detail?id=691599. There's also a series of whatwg issues about exposing trailers in the fetch API: https://github.com/whatwg/fetch/issues/34 https://github.com/whatwg/fetch/issues/34. For a protocol that sits above L7, the gRPC HTTP/2 protocol is liberal about diving past the semantics outlined in RFC 9110 and specifying transport-level details. (As an example, trailers-only responses must be sent in a _single_ HTTP/2 headers frame with the EOS bit set.) That degree of specificity unlocks some performance gains, but it makes it near-impossible to speak this protocol using an existing HTTP library - a traditional strength of building on top of L7. For broad adoption in a _lot_ of environments, gRPC-Web (and Connect) are IMO much better protocols.

fizx 4y ago

There seems to be two groups of protobuf libraries for HTTP 1.1, the ones that want to make it look like binary+HTTP/2 grpc (grpc-web, grpc-gateway), and the ones that make it look like idiomatic web tech (twirp). I'm excited to see more ideas in the second category.

mf192 4y ago
Curious, do you see connect-web falling into the former or the latter group?
jrockway 4y ago
grpc-gateway is actually in the second class. It allows you to annotate your protobuf so as to create a JSON + HTTP method based API (people call this "REST") that is translated to gRPC for your actual backend. (gRPC/Web is protobufs over HTTP/1.1. Different than strict HTTP/1.1 transcoding, though, which is also possible for gRPC to do.) I think grpc-gateway is absolutely what 99% of users want to do. You can generate client stubs (it will even output an OpenAPI spec) like you can do for gRPC + protos, but it's all HTTP/1.1 + JSON over the wire, so if you really want to hand craft curl requests, you can. (But with an OpenAPI spec, you'll really like just plugging it into some GUI tool to make these one-off requests. Even curl diehards like myself.) grpc-gateway is also up front about not supporting things browsers can't do, like bidirectional streaming. gRPC/Web always disappointed me on that front; "coming soon" for years. In the past, I used grpc-gateway (in process, some minor downsides compared to running the gateway as a separate process) + gRPC for my service's internal admin API. It was very few lines of code whenever you wanted to add a new endpoint, and because of the OpenAPI spec, it became available for use in our admin GUI as soon as you pushed the new server code. If someone wanted to add a new endpoint, there was basically no tedium, edit the proto, "go generate ...", implement the generated interface with your actual functionality, push to production. We embedded the generated OpenAPI spec in the doc, so you could just point at app.example.com/OpenAPI.json and clients would auto-update to see your new endpoint.) I actually converted in-place a hand-coded REST API; all the requests and responses and endpoints stayed the same (thanks to the power of the grpc-gateway annotations), but I deleted all the code in every handler that did the marshaling and unmarshaling. The result was something that was very easy to add to and maintain. I liked it a lot and would do it again without hesitation. (We used Retool as the GUI. Not sure I'd recommend it, but it worked fine. I've seen some HN posts about open source alternatives, those look awesome.) I have also written several apps that use gRPC/Web. I didn't find the experience bad, but the Javascript bundle size is huge, so I never felt great about it. grpc-gateway should be the first thing you look at, your server code will be simple, and your client code will be small. And hey, if you have non-web clients, plain gRPC is great too.

halfmatthalfcat 4y ago

gRPC-web just isn't there yet but appreciate the work in the space. There's also an issue with a proliferation of transpilation (protoc) projects: - grpc-web (the standard binary protocol) with the optional TS emit - grpc-web-text with the optional TS emit - gprc-ts - ts-proto Which to use when, why and the issues with interop between backend/frontend server implementations. Also the streaming story isn't great. Also the need for Envoy as another piece of infra to manage isn't great either.

mf192 4y ago
You're right, gRPC-web isn't there and likely won't get there. That's why we need something like connect-web. - no proxies - smaller bundle size - idiomatic TS code in both runtime and generated code - streaming - ... and more
lucas_codes 4y ago
What is grpc-web-text?
- akshayshah 4y ago
  It's a variant of the gRPC-Web format that base64-encodes the request and response bodies. It was designed for very old browsers that don't support the fetch API and can't send/receive binary data. All those browsers have been end-of-lifed, and they now represent a tiny fraction of web users. In short, it's a relic of a bygone age.

theogravity 4y ago

I would really emphasize the no proxy required part in the intro of this post. To me its one of the huge factors for not using grpc from the web.

rektide 4y ago
But your services have to support the Connect protocol. You can also ship services that support gRPC-Web directly too & run without a proxy. This is definitely a step up, nicely convenient. But also, it has downsides too. gRPC is incredibly well supported by a huge number of observability tools and service-layers/service-mesh systems. Few have support for gRPC-Web. Which if any have support for Connect-Web? In general, it's just massively sad that the browser never got around to making HTTP Push useful for protocols. gRPC should have been positioned to do great things, was a very common-sense overlay atop HTTP2 that provided just a little more semantics to say how things ought work. It triangulated nicely on where we were going, at it's inception, back in 2014/2015. But the browser basically never evolved, never gave developers access to do the good stuff we thought we'd start to have access to. I still see brand new specs that shout out to the Low Level Extensibility Manifesto[1], but for some reason, in terms of the most base layer of the web, HTTP, this simple guidance has been roundly ignored & the capabilities were never delivered. So gRPC has been stuck with a pretty ok protocol, & frustratingly discompatible browser. [1] https://github.com/extensibleweb/manifesto https://github.com/extensibleweb/manifesto
- sjroot 4y ago
  Yeah this is the deal breaker for me as well. This smells like an embrace-extend-extinguish campaign frankly? 1. Embrace gRPC and protobuf 2. Extend with Connect, get everyone using this in their APIs and web apps 3. Drift away from established gRPC and/or protobuf standards, build platforms/business around this and trap as many folks as possible As silly as it may seem, one thing that really sends this signal for me is the nice trademark symbol on the Buf name. their intention for all of this stuff is to build a business.
  - akshayshah 4y ago

newaccount2021 4y ago

deleted 4y ago

[deleted]

89vision 4y ago

I once worked on a home built browser grpc implementation where the protobufs were serialized over the wire in base64. It certainly had it's kinks to work out, but sharing/generating the service definitions and models from the same protobuf markup between backend and frontend was really nice.

nine_k 4y ago
Doesn't OpenAPI (née Swagger) give you the same for plain HTTP + JSON?
- AtNightWeCode 4y ago
  Yes, you can even generate models from JSON directly. Then there is JSON Schema and other schema first options that mostly no one uses anymore.
- 89vision 4y ago
  yeah, I've done both, but I far prefer writing protobuf markup than swagger. YMMV
miohtama 4y ago
I was working with Cosmos nodes in a hackathon and they did RPC where one had Protobufs embedded as base64 encoded within JSON.

lotw_dot_site 4y ago

No demo. I was wondering what kinds of things I could be doing here that I couldn't do before (with websockets, webrtc, etc) but demo.connect.build just redirects to connect.build. I'd only known of "Protocol Buffers" as something that was internal to Google, but never knew exactly to what end.

lotw_dot_site 4y ago
Nevermind, I see the demo is the Eliza widget on the main page. So, I can do Eliza with it then... I'll keep that in mind for the next time that I need to get an Eliza widget working ;)
akshayshah 4y ago
The little demo application is on the connect.build homepage and on https://connect.build/demo https://connect.build/demo. I completely forgot to fix the redirect from demo.connect.build to point to the actual demo page - thank you for reminding me :) Protocol Buffers are just a schema language. They're spiritually akin to OpenAPI, Thrift, Avro, and a bunch of other contract-type things. They're _also_ a binary serialization format that's usually faster and more compact than JSON. The intention is to use Protocol Buffers as a language-independent way of describing data bags and network APIs, and then use that schema/contract to generate code in the language you actually work in. It's not that you _can't_ do that with websockets, webrtc, or just RESTful HTTP/1.1 - it's that you shouldn't _need_ to. The hand-written code to define the same data bag classes/interfaces/structs/etc in multiple languages, then wire them up to the same HTTP boilerplate isn't difficult or interesting, it's just toil. For all the times you're just calling an API, Protobuf lets you get on with the interesting work and skip the boilerplate. Ideally, things work well even if you're writing client code in a language that the server team doesn't have any expertise in. If you're doing something unusual and need webrtc/websockets/etc, go for it!

boardwaalk 4y ago

It looks like the Connect protocol supports client streaming, which gRPC-Web doesn’t, but the only way for a server to speak connect-web is to write it in Go and use their libraries? What about servers in other languages? Are there any plans for f.e. Envoy support for going from Connect the frontend to gRPC on the backend? Like gRPC-Web to gRPC?

akshayshah 4y ago
The gRPC-Web _protocol_ supports streaming - it supports everything that standard gRPC does.* The client libraries that operate in web browsers don't support client streaming, because every major browser currently buffers request bodies. Right now, you're correct - the easiest way for another server to speak the Connect protocol is to use connect-go. We're planning to support more backend languages soon: Node.js is up next, with the JVM maybe afterwards. We'd also love to contribute (time, code, review, whatever) to any other backend implementations - the protocol is not that complex. File an issue on one of our projects or ping us in our Slack, it'll probably be an easy sell. Envoy support is complicated. The honest truth is that we haven't looked into it all that much because it feels rude - Envoy's architecture requires first-party plugins to live in the main repo, and it feels impolite to attempt a C++ code dump for our new project. Maybe once Connect takes the world by storm :) Even if we did do that, a Connect-to-gRPC translation layer would only work for binary payloads - converting JSON to binary protobuf requires the schemas, and redeploying proxies every time the schema changes is an operational nightmare. * Worth noting that gRPC-Web doesn't really have a specification. There's a narrative description of how gRPC-Web differs from standard gRPC, but they specifically mention that the protocol is defined by the reference implementation in Envoy.
- boardwaalk 4y ago
  Thank you for the detailed reply! Random thoughts: I personally would not mind requiring Protobuf payloads so the proxy portion can stay dumb — keeping proxies up to date sounds no fun. Losing inspectability (not having JSON) is a minus but not a deal breaker. Requiring servers to use a new library is a big lift for people, and hard to sell if what you have works. Having a proxy you can drop in the meantime, while getting client streaming at the same time, seems nice. In any case, having the shiny Typescript friendly libraries that can easily switch between gRPC-Web and Connect is nice, so thanks for that. For what it’s worth, our servers are C++ and use Arrow Flight which why I’m even interested in client streaming at all (its DoPut method has a streaming argument). My current solution is to add a regular gRPC method that behaves similarly to DoPut but is a unary call for browser clients. Not terrible, but it’d be nice to not have to do that. I may well take you up on filing an issue/pinging y’all on Slack.

masukomi 4y ago

protobuffers are no end of pain for me at work. Yes, the guarantee of no breaking changes in an API is wonderful. Everything else sucks. Not being able to use JSON to test your api? sucks. Having to convert the changed .proto files to a new library for your language (gem for ruby in my case) and then have your system use that instead of the latest release (because you haven't tested it yet) sucks. A terrible ruby library written by people who were obviously not ruby devs (it makes FooServiceService classes for example)? sucks. hoop-jumping to force a breaking change in something you thought was good, but isn't and hasn't been released yet? Sucks horribly degraded iteration loops on new functionality? sucks not being able to host it anywhere that doesn't support HTTP2 (Heroku)? sucks Unless you're working on something at google scale and the performance difference and bandwidth savings are actually noticeable RUN FOR THE HILLS. Protobuffers will bring you nothing but pain.

francislavoie 4y ago
Seconded, for PHP. It's such a nightmare to work with.
aseipp 4y ago
Also, even if you do want to have some kind of binary-ized transport with a strict type-checked schema and compilers for multiple languages -- ultimately a noble goal, I think -- there are much better options available, design and technology wise. Cap'n Proto is wonderful with a very strong foundational design and good implementation, it's major drawback being a relatively sparse set of working languages, and a lack of tooling. But then again the quality of 3rd party Protocol Buffers libraries has always been a complete gamble (test it until you break it, fork it and patch it to make due), and as you note the tools aren't all there for gRPC either. So in general I completely agree. If you are exposing a Web API to consumers -- just keep doing RPC, with HTTP APIs, with normal HTTP verbs and JSON bodies or whatever. Even GraphQL, despite having a lot of pitfalls, and being "hip and fancy", still just works normally with cURL/JSON at the end of the day because it still works on these principles. And that matters a lot for consumers of Web APIs where some of your users might literally be bash scripts.
franciscop 4y ago

vosper 4y ago

If you've got Typescript on front-end and back-end then I'd recommend looking at tRPC. The schema is your types, which might often just be the type of your DB response, leading to low-code but fully type-safe coding. https://trpc.io/ https://trpc.io/

sgammon 4y ago
pretty useless as an RPC layer if it imposes language restrictions…
- bluepizza 4y ago
  Why?
  - sgammon 4y ago
    Because the point of an RPC layer is to communicate between pieces of software, and you often have no guarantee of control over the languages they are written in.
    - bluepizza 4y ago
      That’s true for microservices environments in modern companies. But a lot of traditional companies have languages and versions locked and mandated. The point of RPC layer is just to remotely call a procedure.
akshayshah 4y ago
tRPC is awesome - if you're writing full-stack TypeScript and don't care about other languages, it's very convenient. Protobuf might be a more appealing choice if you want to support clients in other languages, or if you're interested in getting a bit more value out of your contract language (e.g., breaking change detection).
junon 4y ago
Or just use AJV which has the ability to statically represent JSON Schemas as full-fledged types, so that the schemas themselves become the authoritative IDL, via the new JSONDataType in AJV@7.

fyrn- 4y ago

Cap'nProto Is so much better. Really a lot are, but Cap'nProto is main by the original protobuff dev so his description of why he made it is relevant. I use protobuff everday at work and honestly the generated code is incredibly awful conpared to pretty much any alternative. We're way to bought in to switch now though sadly.

melony 4y ago
There aren't enough good cap'n proto code generators (compared to protobuffs/flatbuffs). It is not viable unless your stack is mainly C++.
- junon 4y ago
  I use it in Rust just fine, FWIW.
kentonv 4y ago
Hi. That's me. I'm glad you like it. Unfortunately, melony is right: I've only really been able to focus on the C++ implementation of Cap'n Proto. Some of the others are solid (e.g. Go, Rust), but many are sort of half-baked weekend projects of random people, which were later abandoned. As a result it's tough for me to recommend Cap'n Proto in polyglot environments. Maybe someday I'll be able to find the time / resources to build out the ecosystem more fully. Great tooling is really important for any of this to work. I'm also an investor in Buf FWIW. I think what they're doing is pretty cool.
- junon 4y ago
  Hi, I like capnproto as well, thanks for making it. :)
djbusby 4y ago
Which are better? I don't even have a big list of xRPC/xBuf tool - only know of two (now three). Can you point to others?

mosdl 4y ago

Has anyone used their protobuf-es library? Seems interesting and better than the other libraries from a quick glance. I wonder if there are bazel rules for it.

akshayshah 4y ago
Probably not - we wrote it alongside connect-web, so it also launched very recently :) We do think it's the best option for protobuf code generation in TypeScript, though. It comes from quite a few years of experience with proto & TS: the primary author is also the author and maintainer of protobuf-ts, and we had the author of ts-proto review it and give us a thumbs-up before launch. There _could_ be Bazel rules for it - we certainly write enough other Bazel integrations. Mind filing an issue on https://github.com/bufbuild/protobuf-es https://github.com/bufbuild/protobuf-es?
- mosdl 4y ago
  Sure, opened an issue.

sgammon 4y ago

I am so incredibly excited about this. Buf is an amazing tool that every proto developer should know Great work Buf team

AtNightWeCode 4y ago

This is not the first attempt to run gRPC from web. It is still a bad idea since it does not play nice with common web infra. I don’t understand what one even tries to accomplish with this.

biggestlou 4y ago
I strongly suggest that you read the post to see why this project is different and specifically intended to place nicely with common web infra.
- hamandcheese 4y ago
  The post says it is a post-only API. I’m not sure if thats to a single URI, like graphql, or if the URI is different depending on the RPC call in use. But either way, it sounds like cacheability might not be great, which is also an issue with graphql. That said, it’s definitely a step in the right direction, and I personally have never written an API where I even wanted the results to be cached.
  - bufbuild 4y ago
    The URI is per-RPC, specifically at /service/method, if that helps. On cacheability, do check out https://connect.build/docs/protocol#future-extensions https://connect.build/docs/protocol#future-extensions - it’s something we continue to put thought into to make sure we get it right.
- AtNightWeCode 4y ago
  I understand that is does not come with a proxy which is a leap forward. GETs are often optimized in various ways and gRPC is designed for reusing channels.
upbeat_general 4y ago
Perhaps unifying tooling/infra if you’re already using gRPC for your services.
4y ago

FpUser 4y ago

Been using post only JSON based RPC of my own cooking for ages. Worked well for me and my clients.

yandie 4y ago

But then we have to use yet another protocol?

timostamm 4y ago
If you want to be able to see data in the browsers network inspector, you do. If you are already serving gRPC-web, you can use the gRPC-web transport in connect-web, it supports both protocols. It doesn't support plain gRPC because web browsers do not expose trailers, and gRPC uses them extensively.

time4tea 4y ago

I just love how a zero byte protobuf message deserialises into a valid struct. Very reassuring.

net_ 4y ago
In the other direction, the "all fields at default value serializes as size 0 message that you can't send" behavior has been an unending annoyance since switching to proto3.
jeffbee 4y ago
That's the example I always use for the people who say that protocol buffers are "type-safe" which they emphatically are not. Any empty buffer will successfully decode as any message that has only optional fields!
- dathinab 4y ago
  the idea of protobuf is "init to default value and then incremental merge message fragments". Which is even more crazy then missing parts have default value, when you consider how that behaves in some cases of mismatching schemas (it also can introduce annoying limitations when trying to create idiomatic libraries in some languages, especially such with "type-safety"). And then add in some of the "automatic type conversions it does". And to top if of some edge cases tend to very often diverge in implementations of different languages, no matter what the original intention was. And the result is uh, just uh, very very uh. I understand why google uses them, it fits them. It probably a good idea given google scale problems, company and team structure and "skill level" of each member. But that doesn't mean it's a good fit for everyone.
  - jeffbee 4y ago
    To be fair to protobuf, its own docs make no claims about "safe". That is projected upon it by people who do not understand it.
    - xyzzy_plugh 4y ago

victorvosk 4y ago

or... https://github.com/t3-oss/create-t3-app https://github.com/t3-oss/create-t3-app

dathinab 4y ago

But protobuf isn't grate, especially proto v3 is tuned exactly for googles needs, tools and approaches. But googles needs, tools and approaches are not fitting for most smaller companies. And gRPC adds a bunch of additional complexity and failure modes, sure it's worth considering especially for larger projects. But a lot of projects get away just fine with a surprising small number of endpoints.

akshayshah 4y ago
For the most part, we agree! Protobuf isn't perfect. gRPC is _definitely_ optimized for megacorporation-sized problems. No matter who you are, though, it's not fun to hand-write boilerplate data types and fetch calls or quibble over which parameters should go in the path and which should be query params. Even when you're actually sending JSON on the wire and using regular HTTP/1.1 POSTs, Protobuf and connect-web make it easy to skip right to the interesting part of your code.
- 0x001D 4y ago
  I'm curious how flexible one is if proto3 is given as it is from a schema perspective, where a true schema/constrains language like CUE could be a vehicle to define schemas and then transform that to anything needed, like protobufs or even stubs serializing on the wire.

maerF0x0 4y ago

For those griping about using JSON manually with their APIs ... This tool is a big help for working with GRPC (at least from cli) https://github.com/fullstorydev/grpcurl https://github.com/fullstorydev/grpcurl

FridgeSeal 4y ago
There’s also BloomRPC, which is like Postman/Insomnia for GRPC: https://github.com/bloomrpc/bloomrpc https://github.com/bloomrpc/bloomrpc
- bufbuild 4y ago
  And there’s Buf Studio :-) https://buf.build/blog/buf-studio https://buf.build/blog/buf-studio https://studio.buf.build https://studio.buf.build
- nsxwolf 4y ago
  Insomnia and Postman also support gRPC now as well. Lots of choices.
  - FridgeSeal 4y ago
    I found insomnia's grpc support a bit lacking - notably, it won't refresh the grpc definitions from disk without reloading your whole environment, and doesn't auto-populate the window with the keys. The latter is a more minor concern, but when you have larger protos it does become annoying.

rdevsrex 4y ago

Unless you are already working with them, I'd much prefer using tRPC.

meisel 4y ago

I generally find Protobuf the serialization format to have no benefits over JSON. Although Protobuf is often thought of as being faster to process and more compact, the reality is that it's usually not (at least as long as you're not working in a systems language like Rust or C++). It's not much faster than JSON to process because in the context of higher-level languages, the time to create usable objects out of the parsed input (which is independent of the serialized data they came from) is usually far larger than the time to parse the payload. And as for being more compact, if you gzip a Protobuf payload and its JSON equivalent, IME they end up being pretty close in size (sometimes the JSON version is actually smaller).

mkoryak 4y ago
What about the benefit of being able to represent data types like Date, double vs float vs byte etc ?
- klysm 4y ago
  ISO8601 gets you pretty far with dates and you can always quote your numbers - most serialization frameworks support that
zeroxfe 4y ago
We migrated many of our critical protocols from JSON to protobuf, and the experience has been very positive. As your system gets bigger, and your teams get bigger, the value of a typed schema has a multiplicative effect on both reliability and productivity. In addition, a lot of basic features around managing transport, like load balancing, health checking, deadlines, etc. come out of the box. IMO, performance is the least of the reasons to use protobufs. And if you're working on simple systems in small teams (or solo), then JSON is a better fit (because it's simpler to understand, debug, and iterate with.) gRPC is definitely not a one-size-fits-all.
- nwah1 4y ago
  Swagger/OpenAPI offers a typed API in JSON (along with generated clients just like gRPC). The complaints about protobuf as a serialization format remain valid, and you don't need it to have types. Also the reability of JSON in-transit is another factor to consider.

upbeat_general 4y ago

My biggest gripes with Protobufs is the language integrations. Why do I need to convert and typecheck back and forth between the proto object and the native dataclass. This was the situation in kotlin (and I believe Java) as of about a year ago though I hope it’s changed by now. We had to have several hundred lines of totally unnecessary manual type checking to validate input/output when that should be a major strength of protobufs.

denkmoon 4y ago

Back in my day we had a language for transferring data between systems in a human readable format and it even has typed schemas, and provided you're not reinventing the wheel, it's easy to work with programmatically too. XML is the language of the gods.

sagarm 4y ago
XML is inefficient to read and write by both computers and humans; might as well use JSON as your serialization format, it's at least more human readable.
- denkmoon 4y ago
  Use JSON and you lose type information, schemas, and relationships. Of course you can add all that back to JSON as many people have done in various ad-hoc ways. JSON is inferior to XML in every way except "I don't want to type angle brackets and closing tags". I encounter a lot of people stating your position, that reading JSON is faster than reading XML, for a human. I cannot speak to the subjective experience of anyone but myself of course, but IMO that's a load of bunk. Spent most of my career looking at both XML and JSON, and the only time I ever have a problem is when it's not formatted/indented. We have tools for this, of course. Yet to encounter a situation where the performance of the XML parser was a limiting factor in the system I am working on. RapidXML and RapidJSON are both insanely fast if you use them as intended. If you are encountering performance issues from parsing XML you almost certainly want to move to a binary format anyway.
  - sagarm 4y ago
    I don't want to type or parse duplicate tags and angle brackets. It's nonsense for a human readable format. I work on low latency distributed systems where performance does matter. We use proto wire format mostly. Proto has its own human readable text format that I prefer because it's more convenient than JSON (no commas, unquoted keys), but I'd pick JSON over XML any day.
8n4vidtmkvmk 4y ago

raggi 4y ago

Are they using real binary protos yet, or is that still only a third party game? Years ago the dcodeio libs were much better than stuff Google was shipping for the web.

CMCDragonkai 4y ago

We had major problems with integrating grpc into electron and browser extensions so making something like grpc work on the web is essential. However for a decentralised application, expecting users to deploy a separate proxy is unacceptable. So we were planning to switch back to json RPC and build our own streaming system based off vscode's json RPC. Does this new connect protocol expect to support all streaming mechanisms client streaming, server streaming and bidirectional?

bufbuild 4y ago
It already does! The connect protocol supports all streaming mechanisms. The beauty of the Connect ecosystem is that no proxies are required - the Connect protocol works just as well from the browser as it does on the backend.

lucas_codes 4y ago

I'm rather a fan of using gRPC in a stack. It has its cons, but you get a generated client/server that is type-safe, even across different languages. Would love to hear alternatives which do the same thing. I know one possibility is OpenAPI specs generated from Django Rest Framework.

jahewson 4y ago
GraphQL has great tooling for this kind of thing and its web-friendly by default.

istillwritecode 4y ago

Typescript: uh no.

grosskur 4y ago

Congrats on the launch! It's great to see more innovation and choice in the protobuf/gRPC space. Definitely planning to try this out. For personal projects, I typically have a single Go binary that serves (1) gRPC, (2) grpc-web (using the Improbable library), and (3) gprc-gateway. Along with protobuf-ts for the client, IMO it's quite a pleasant stack. Glad to see timostamm involved in protobuf-es :) I'm curious: Can you say more about why you ported the code generator from Go to TypeScript (https://github.com/bufbuild/connect-web/commit/8002c2696aad0b6125050202db6341ba2178c5f7 https://github.com/bufbuild/connect-web/commit/8002c2696aad0...)? Was it is easier to generate code this way, or did it just get too unwieldy to package Go binaries in NPM modules?

akshayshah 4y ago
Timo is amazing, and we wouldn't have been able to build any of this without him :) We ported the code generators to TypeScript because - as you guessed - it was a bit of a pain to package them for NPM. We also felt that it would be more approachable for TypeScript developers to read, which we hoped would contribute to a sense that all of this isn't actually all that complex. We were a bit worried that performance might be perceivably worse, but the difference wasn't significant.
lf-non 4y ago
Improbable's grpc-web [1] works pretty well. I have been using it along with their new websocket transport for about two months and as an RPC layer its great. However I do miss being able to inspect the traffic in devtools, and the TS sdk is still not ESM friendly and requires jumping through hoops to get working with vite. So we ended up bundling it separately through esbuild (along with other google protobuf deps etc.) to a large single file ESM module that other projects can easily consume. Buf seems to be a solution that handles all of this better. Very excited to try this out. [1] https://github.com/improbable-eng/grpc-web https://github.com/improbable-eng/grpc-web

jitl 4y ago

I’m interested in these “gRPC but we care about devs outside of Google” kind of libraries! I see you’re working on generating idiomatic Typescript from Proto3 - but have you thought about generating Proto3 from Typescript? At Notion we have 1000s of lines of TS types and many TB of JSON stored in those shapes already. Rewriting all that to Protobuf by hand is kinda a non-starter. So we need to go the other direction at least initially. I started on a Typescript type -> Proto3 compiler that’s very much still in the “toy” stage. I’m also working on compiling Typescript typed to Thrift, JSOMSchema and Python; I plan to experiment with Kotlin as well after the Proto3 target is a little less janky. My work in progres branch is here, in case this is useful or you want to collaborate! Proto3 compiler: https://github.com/justjake/ts-simple-type/blob/jake--compilers-as-features/src/compile-to/proto3.ts https://github.com/justjake/ts-simple-type/blob/jake--compil... Example input and output: https://github.com/justjake/ts-simple-type/blob/jake--compilers-as-features/test/snapshots/compiler.spec.ts.md#compile-toproto3-compile-testts-to-proto3 https://github.com/justjake/ts-simple-type/blob/jake--compil...

aabbcc1241 4y ago

Protobuf may make sense for static type language, but the DX for dynamic type language like javascript and python is suboptimal. If you really need binary encoding to save some bandwidth, msgpack maybe good enough.

leshenka 4y ago

https://archive.ph/4ou6j https://archive.ph/4ou6j just in case it returns 403

est 4y ago

An example of protobuf working on websites is play.google.com And it sucks balls.

mtoohig 4y ago