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

Add gRPC + grpc-gateway routes as alternative to legacy tendermint REST endpoints #7719

Closed
clevinson opened this issue Oct 29, 2020 · 2 comments · Fixed by #7965
Closed

Add gRPC + grpc-gateway routes as alternative to legacy tendermint REST endpoints #7719

clevinson opened this issue Oct 29, 2020 · 2 comments · Fixed by #7965
Assignees
Labels
Milestone

Comments

@clevinson
Copy link
Contributor

clevinson commented Oct 29, 2020

The SDK currently exposes the following REST endpoints as thin wrappers over tendermint:

  • GET /node_info
  • GET /syncing
  • GET /blocks/latest
  • GET /blocks/{height}
  • GET /validatorsets/latest
  • GET /validatorsets/{height}

In keeping with how we are marking all other non GRPC-gateway based REST endpoints as deprecated (#7686), we need to decide if these endpoints should also be considered deprecated, and if so, what alternative endpoints we communicate users to use instead for Stargate chains.

The options as I see them:

  1. Leave endpoints as is (undeprecated), and continue supporting these endpoints for Stargate, not deprecating until we have a bigger aligned plan with tendermint's future use of grpc and/or grpc gateway
  2. Mark as deprecated and write GRPC + GRPC services exposing the same functionality via standard Cosmos SDK grpc(+gateway) interfaces
  3. Mark as deprecated and tell clients to query tendermint RPC directly for these queries

Would be good to hear from someone on the Tendermint side about this as well-- possibly @marbar3778 ?

cc @amaurymartiny (see original comment here)

@amaury1093
Copy link
Contributor

(2) seems like the way to go to me 👍

I don't think it's super high priority to add these gRPC services now, but it would be a good task for 0.40.1.

@aaronc aaronc added the backlog label Oct 29, 2020
@alexanderbez
Copy link
Contributor

My vote is for (2), and sooner rather than later 👍

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

Successfully merging a pull request may close this issue.

5 participants