@@ -32,7 +32,8 @@ They are similar, but GRPC-WEB target is to be as close to GRPC as possible, whi
3232web-friendly: it has better client libraries, better web semantics:
3333content-type is ` application/json ` instead of ` application/grpc-web+json ` , error codes are just normal http codes
3434instead of being sent in headers, errors are output in the body of the response JSON-encoded, it supports GET-requests,
35- etc (you can also read this [ blog post describing why ConnectRPC is better] ( https://buf.build/blog/connect-a-better-grpc ) ).
35+ etc (you can also read
36+ this [ blog post describing why ConnectRPC is better] ( https://buf.build/blog/connect-a-better-grpc ) ).
3637
3738Both protocols support encoding data in Protobuf and JSON.
3839JSON is more web-friendly, but it requires having some component in the middle, providing JSON → Protobuf
@@ -109,6 +110,31 @@ val httpServer: Resource[IO, org.http4s.server.Server] = {
109110httpServer.use(_ => IO.never).unsafeRunSync()
110111` ` `
111112
113+ # ## Tip: GRPC Opentelemetry integration
114+
115+ Since the library creates a separate "fake" grpc server, traffic going through it won't be captured by the
116+ instrumentation of the main grpc server.
117+
118+ Here is how you can integrate the Opentelemetry with the Connect-RPC server :
119+
120+ ` ` ` scala
121+ val grpcServices: Seq[io.grpc.ServiceDefinition] = ??? // Your GRPC service(s)
122+ val grpcOtel : GrpcOpenTelemetry = ??? // GrpcOpenTelemetry instance
123+
124+ ConnectRpcHttpRoutes.create[IO](
125+ grpcServices,
126+ Configuration.default
127+ // Configure the server to use the same opentelemetry instance as the main server
128+ .withServerConfigurator { sb =>
129+ grpcOtel.configureServerBuilder(sb)
130+ sb
131+ }
132+ )
133+ ` ` `
134+
135+ This will make sure that all the traffic going through the Connect-RPC server will be captured by the same
136+ opentelemetry.
137+
112138# # Development
113139
114140# ## Running Connect-RPC conformance tests
0 commit comments