Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Understanding the parameter RequestData in the method InvokeRPC call #477

Open
ravikanthdba opened this issue Jul 28, 2024 · 2 comments
Open

Comments

@ravikanthdba
Copy link

We have a use case where we are developing an observability platform, where users define their own sources, which are different gRPC endpoints with different structures.

The platform that we are building should be able to fetch the dynamic gRPC endpoints and figure out the proto files dynamically, and we came across https://github.com/fullstorydev/grpcurl which exactly solves our purpose.

The only issue is when we are triggering InvokeRPC, I'm unable to understand what needs to be given in requestData. Could you please help with a small example on how to trigger InvokeRPC, that would be of a great help to us.

Thanks,
Ravikanth

@jhump
Copy link
Contributor

jhump commented Jul 29, 2024

@ravikanthdba, the requestData argument is what the InvokeRPC function uses to retrieve the actual message data to send.

So you would provide a function that populates the given message with the request data. It may be called multiple times, in which case the function should return io.EOF to indicate there is no more request data. This is used for streaming requests, where each invocation of the function that does not return an error populates another message in the request stream.

This "inversion of control", where invocation asks for the request data, instead of the caller actively providing it, was done to make the CLI use case simpler and also makes use in a proxy simpler. For example, in a proxy, this can be wired up to call the stream.RecvMsg method on the grpc.ServerStream that is being proxied.

If your use case instead warrants your application code to imperatively "push" the request messages, you'd need something more sophisticated, like a channel that can be used as a pipe between your application "send" code and the request supplier function.

@ravikanthdba
Copy link
Author

Thanks for the response @jhump . I was able to figure out. Would it be better to add examples for how to make an InvokeRPC with an example? just makes it little more clear as to how to do it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants