Open sameerajayasoma opened 1 year ago
I also thought about introducing message types instead of just primitive types. When we specify a message type in the proto definition, the corresponding Ballerina message type is in the generated stub(pb.bal
) file, which is not shown in our example. The example is not complete without mentioning the input and output message definitions.
But we can't add them in the examples because it brakes the flow. Users have to manually delete the records in the example as they are in the generated files.
This issue is there in the bidirectional streaming example[1]. there we didn't mention the input ballerina type(ChatMessage
) in the example.
Our example will get complex and lengthy if we show the routeguide example[1] in BBEs. IMO this should be a part of a guide.
See the following links. https://github.com/grpc/grpc-go/blob/master/examples/route_guide/routeguide/route_guide.proto https://grpc.io/docs/languages/go/basics/ https://grpc.io/docs/languages/java/basics/ https://grpc.io/docs/languages/kotlin/basics/
In that RouteGuide gRPC service, there exists an RPC method for each of the following scenarios:
The current examples (https://pre-prod.ballerina.io/learn/by-example/grpc-service-simple/) use string type as the param and return type. It would be better to use messages. That way, we could achieve real-world yet straightforward examples.