Road to v1 #315
Replies: 10 comments 19 replies
-
|
The past six weeks have been quite busy. We're glad to share that we have clients and servers for the Connect, gRPC, and the gRPC-web protocol roughly working in Node.js 🎉 A couple of features are still missing, for example compression support in all protocols, and support for deadlines. After implementing those missing features, we will focus on streamlining the implementation and shaking out bugs. We plan to publish a first beta in January. We're thrilled about the amount of feedback we've received already. We truly appreciate that, thank you! Regarding Protobuf-ES, we are about to release a v1 in the next couple of days. That doesn't mean we are done, but we think it is mature enough to cut a stable version. |
Beta Was this translation helpful? Give feedback.
-
|
Hello! First of all, thank you very much for this work. ❤️ |
Beta Was this translation helpful? Give feedback.
-
|
Hey Johyn, that's right, all methods on clients take an optional On the server, you can always throw a ConnectError, for example with |
Beta Was this translation helpful? Give feedback.
-
|
Hey! Thank you very much for this information. But there is still one point I don't understand, how is the server informed when a call is cancelled? Thank you very much in advance. |
Beta Was this translation helpful? Give feedback.
-
|
Cancelling a request via |
Beta Was this translation helpful? Give feedback.
-
|
OK thank you very much, I will go and study the gRPC protocol in detail. |
Beta Was this translation helpful? Give feedback.
-
|
Does connect-web (or connect-nodejs or maybe connect-edge) aim to be WinterCG spec compliant? proposal-common-minimum-api is here. |
Beta Was this translation helpful? Give feedback.
-
|
This would be game changer. Found this. They say |
Beta Was this translation helpful? Give feedback.
-
|
Hey @matamatanot, that's an excellent question. Everything we've done so fair aims to be as universal as possible. We took a stab at using WHATWG streams (PR), but that actually showed a couple of problems in practice (described here). We have since switched handlers to asynchronous iterables (PR), and are currently doing the same for clients. Because asynchronous iterables are a (widely supported) language feature, it is relatively straight-forward take an arbitrary stream implementation like WHATWG streams or Node.js streams, and make the stream available as an asynchronous iterable. The Node.js specific code is actually a rather slim layer that should be straight-forward to be adapted to - let's say the Deno standard lib. So yes, we aim to be compliant to the Minimum Common Web Platform API. But please be aware that the connect-node package has to be specific to Node.js to provide a decent developer experience, and can't run on an arbitrary platform without specific bindings. We're looking forward to get this out the door and get feedback from the community, including learning where you would like to use it besides Node.js. |
Beta Was this translation helpful? Give feedback.
-
|
That makes sense, thanks for the update @timostamm . |
Beta Was this translation helpful? Give feedback.
-
|
A quick update: We had to go through a couple of iterations of a streams abstraction, but the dust is settling 😄 |
Beta Was this translation helpful? Give feedback.
-
|
Hello, thank you very much for this work! I don't know if this is the best place for this, but I thought I'd share my use-case with I actually have a server stream RPC named const service: PubSubService {
async* listenToChannel(request, { signal }) {
const iterable = pubSubClient.topic(request.topic, { signal });
for (const message of iterable) {
yield new ListenToChannelResponse({ message });
}
},
};The idea is that every request uses the pub sub client to start receiving messages on a topic. The signal, which is an Will this use case be implementable using Thank you very much in advance! |
Beta Was this translation helpful? Give feedback.
-
|
Johyn, we do not support this use case yet, but we intend to. In any streaming RPC, you definitely want good control over the lifetime and cancellation! gRPC and Connect have the concept of deadlines, but there is also the potential for the client to just hang up. In those situations, we need to ensure that the RPC implementation is notified, and has the ability to clean up, for example close a database connection, an open file, or - in your case - a downstream subscription. All handlers already take a second argument, a But in many cases, there isn't much you can do with an |
Beta Was this translation helpful? Give feedback.
-
|
Any updates on this? What is the best way at the moment to release resources if a client has closed the connection (mainly via |
Beta Was this translation helpful? Give feedback.
-
|
Hey @Sanger2000, the feature was merged in #591 last week, but has not been released yet. The link has a more detailed explanation and examples. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @timostamm! Reading the code, I have the impression that this signal will not be aborted when the request is closed, only when the deadline is triggered. Am I wrong? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @johynpapin @Sanger2000. Hardening our clients and handlers is something we are working on currently. There are a few scenarios we want to address and write tests for prior to a v1 release and this is on that roadmap. You are correct that this PR involves deadlines and not explicit cancels, so it may not handle your exact use case. However, we're hoping to account for explicit cancels in some upcoming improvements. |
Beta Was this translation helpful? Give feedback.
-
|
We just release the Preview of Connect for Node.js in v0.7.0 🎉 You can find a simple example here, and some documentation will be added to https://connect.build/ shortly. |
Beta Was this translation helpful? Give feedback.
-
|
Connect for Node.js is now officially released 🎉
|
Beta Was this translation helpful? Give feedback.
-
|
Does buf Connect support Flutter? There is a Flutter package that references grpc-web support: https://pub.dev/packages/grpc |
Beta Was this translation helpful? Give feedback.
-
|
There is no implementation for Flutter specifically yet. As of today, we have implementations for:
That means you can spin up a connect-go or connect-es server and talk to it from any gRPC, gRPC-web, or Connect client. This includes any of our clients for Kotlin, Swift, Go, web browsers, or Node.js, but also any other gRPC or gRPC-web client like the grpc Dart package. |
Beta Was this translation helpful? Give feedback.
-
|
As you probably noticed, we took a bit of a pivot with v0.8.0. The To solve this problem, we introduced The next steps for us are:
We consider all three to be required for a v1. We are also currently investigating support for other runtimes, but can't tell whether it will be part of a v1 or a follow-up. |
Beta Was this translation helpful? Give feedback.
-
|
Hey there, a quick update: We are still crunching on the bullet points listed above:
Also note that the Connect protocol now supports GET requests in connect-es. You can find out more in the documentation). |
Beta Was this translation helpful? Give feedback.
-
|
Hey there, we just cut the v1 release yesterday 🎉 For testing, we document the tooling and options for web applications here, and for Node.js client and servers here. Note that we also have an integration with Playwright in @connectrpc/connect-playwright, and we plan to support MSW as well. For SSR, most frameworks come with their bespoke technique, although RSC will potentially change the landscape. Connect-ES provides some building blocks for use with SSR boundaries. We provide documentation and examples here. |
Beta Was this translation helpful? Give feedback.
-
|
In terms of RPC testing, I reckon |
Beta Was this translation helpful? Give feedback.
-
|
Service Workers can intercept any request a browser makes, just by registering the worker. Requests can be intercepted conditionally - for example you can intercept requests with a specific payload. So if you want to run tests against a real backend, but intercept only select requests, it gives you some options that are otherwise a bit tricky to achieve. For mocking RPC, |
Beta Was this translation helpful? Give feedback.
-
We don't have any outstanding features blocking a v1 of Connect for Web, but there is outstanding work for Protobuf-ES and Connect for Node.js. We plan to ship a v1 of all three around the same time very early next year. We'll keep this issue updated as we make progress.
Connect for Node.js
There will be a new package
@bufbuild/connect-node, which will export client transports for the Connect, gRPC, and gRPC-web protocols, using the Node.js core packageshttp,https, andhttp2instead of the fetch API.The package will also enable handlers for serving Connect, gRPC, and gRPC-web, so that they can easily be plugged into a vanilla Node.js server, an express or Next.js server.
Because this will enable client-streaming and bidi-streaming RPCs, we are making changes to the
TransportandInterceptortypes to support them. The new shared types live in@bufbuild/connect-core. Once they are stabilized, we will cut a release of@bufbuild/connect-webthat uses them.Update: @bufbuild/connect-node is now available as a preview.
Protobuf-ES - reached v1
If you use Connect for Web, you are using the generated messages from Protobuf-ES. In your UI layer, you might prefer working with plain objects over working with classes, so we are currently investigating generating interfaces in addition to the generated classes. This is tracked in bufbuild/protobuf-es#230.
Note that we are also considering other features like ECMAScript Map for protobuf map fields and support for proto2 extensions, but we will most likely address those post v1.
Connect for Web
If you are using
@bufbuild/connect-web, only interceptors will change slightly (we will provide a guide for switching over). Everything else will continue to work as is, without any changes to your code.Beta Was this translation helpful? Give feedback.
All reactions