Tested in my console-web project(still private, I will open source it after I finish the basic features and views):
js code:

<script>
import { createPromiseClient } from "@connectrpc/connect";
import { createGrpcWebTransport } from "@connectrpc/connect-web";
import { Instrument } from "./gen/instrument_connect";
import { InstrumentRequest } from "./gen/instrument_pb";

const transport = createGrpcWebTransport({
  baseUrl: "http://127.0.0.1:8888",
});

const client = createPromiseClient(Instrument, transport);
const stream = client.watchUpdates(new InstrumentRequest());
(async () => {
  for await (const value of stream) {
    console.log(value);
  }
})();
</script>

console:

I'm not sure how feasible it would be, but is there any way we could include a single HTML+JS file which is able to read from the gRPC-web endpoint as part of this example? Or do we need to pull in too many JS dependencies?

I believe using pure HTML and JavaScript might be somewhat challenging due to the requirement of generating protocol files, necessitating a node.js project. However, I'm open to adding a basic node.js example. My plan is to use 'connect' as it greatly simplifies the process of generating protocol files. What are your thoughts on this approach?

That sounds like a good approach, using connect. I'm not very familiar with JS tech these days, I just think that if we're adding support for gRPC-web then it would be nice to have a small example which shows it in use.

Thank you!

I've updated my PR again.

1. A new API called serve_with_grpc_web will allow users to pass a server build and cors layer and it serve it.
2. For subscriber builder, we only server it with grpc support when grpc-web feature is enabled and users pass a cors layer.
3. Nothing changes to server_with, users can still use it to pass a builder with some basic gPRC settings.

The reason I made this change is that it seems the point of serve_with is not for supporting passing any server builder with layers, it is just for doing some basic gRPC settings. If I am wrong, please correct me. Thanks!

I have a concern about the default port for the grpc-web server. 6669 is a restricted port on chrome. So unless users change it, they won't be able to access it in chrome. So maybe we should change the default port when users enable grpc-web support. But I also worry that this would cause more chaos about the default value. Do you have any suggestions?

I wouldn't dynamically change the default port based on using grpc-web. However, it's probably worth setting the port to some other value in the grpc-web example, perhaps something typical like 8080. And also add a comment stating why a different port is used. That way, at least for people copying from the example, there will be extra information.

Perhaps also adding a line to the documentation for enable_grpc_web stating that some browsers may block the default port 6669 would be a good idea.

However, it's probably worth setting the port to some other value in the grpc-web example, perhaps something typical like 8080.

I've already set it to 9999 before. It worked well on my different browsers. (chrome/arc/firefox/safari)

Perhaps also adding a line to the documentation for enable_grpc_web stating that some browsers may block the default port 6669 would be a good idea.

Added. Thanks for your suggestion!

@hds Before we move forward with this PR, is there anything I need to do?

@hds Before we move forward with this PR, is there anything I need to do?

@hi-rustin Sorry! I thought I merged this already. Done now! Thank you!

Thanks for your review! 💚 💙 💜 💛 ❤️