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

TIP-586: GRPC Implementation for Resource Price Interfaces #586

Closed
lxcmyf opened this issue Aug 29, 2023 · 9 comments
Closed

TIP-586: GRPC Implementation for Resource Price Interfaces #586

lxcmyf opened this issue Aug 29, 2023 · 9 comments

Comments

@lxcmyf
Copy link
Contributor

lxcmyf commented Aug 29, 2023

tip: 586
title: GRPC Implementation for Resource Price Interfaces
author: lxcmyf@gmail.com
discussions-to: https://github.com/tronprotocol/tips/issues/586
status: Final
type: Standards Track 
category : Core
created: 2023-08-29

Simple Summary

GRPC is a high-performance, general-purpose RPC framework open-sourced by Google. This TIP aims to improve gRPC calls for some specific interfaces in Java-tron.

Abstract

Currently, the interfaces /wallet/getbandwidthprices and /wallet/getenergyprices provided by Java-tron do not support gRPC calls. This TIP will implement this function.

Motivation

Currently, /wallet/getbandwidthprices and /wallet/getenergyprices only support HTTP calls. However, this limits developers and users who want to use these interfaces through methods like gRPC, since they won't be able to access historical unit price information of resources through this method. Additionally, it makes it inflexible for external API use.

Specification

As mentioned above, Java-tron will modify the api.proto file to add gRPC implementations of /wallet/getbandwidthprices and /wallet/getenergyprices:

rpc GetBandwidthPrices (EmptyMessage) returns (PricesResponseMessage) {
}

rpc GetEnergyPrices (EmptyMessage) returns (PricesResponseMessage) {
}

message PricesResponseMessage {
  string prices = 1;
}

Rationale

Since the underlying implementation of the two interfaces /wallet/getbandwidthprices and /wallet/getenergyprices has been completed, it is only necessary to open the gRPC implementation entry for them.

Implementation

Since the protobuf protocol has been defined above, it is only necessary to add the gRPC implementation code in RpcApiService.java:

@Override
public void getBandwidthPrices(EmptyMessage request,
    StreamObserver<PricesResponseMessage> responseObserver) {
  try {
    responseObserver.onNext(wallet.getBandwidthPrices());
  } catch (Exception e) {
    responseObserver.onError(getRunTimeException(e));
  }
  responseObserver.onCompleted();
}

@Override
public void getEnergyPrices(EmptyMessage request,
    StreamObserver<PricesResponseMessage> responseObserver) {
  try {
    responseObserver.onNext(wallet.getEnergyPrices());
  } catch (Exception e) {
    responseObserver.onError(getRunTimeException(e));
  }
  responseObserver.onCompleted();
}

In addition, they also support solidity and PBFT API, so gRPC implementations need to be added in RpcApiServiceOnSolidity.javaand RpcApiServiceOnPBFT.javarespectively as well:
RpcApiServiceOnSolidity.java

@Override
public void getBandwidthPrices(EmptyMessage request,
    StreamObserver<PricesResponseMessage> responseObserver) {
  walletOnSolidity.futureGet(
      () -> rpcApiService.getWalletSolidityApi().getBandwidthPrices(request, responseObserver));
}

@Override
public void getEnergyPrices(EmptyMessage request,
    StreamObserver<PricesResponseMessage> responseObserver) {
  walletOnSolidity.futureGet(
      () -> rpcApiService.getWalletSolidityApi().getEnergyPrices(request, responseObserver));
}

RpcApiServiceOnPBFT.java

@Override
public void getBandwidthPrices(EmptyMessage request,
    StreamObserver<PricesResponseMessage> responseObserver) {
  walletOnPBFT.futureGet(
      () -> rpcApiService.getWalletSolidityApi().getBandwidthPrices(request, responseObserver));
}

@Override
public void getEnergyPrices(EmptyMessage request,
    StreamObserver<PricesResponseMessage> responseObserver) {
  walletOnPBFT.futureGet(
      () -> rpcApiService.getWalletSolidityApi().getEnergyPrices(request, responseObserver));
}
@lxcmyf lxcmyf changed the title TIP-600: GRPC Implementation for Resource Price Interfaces TIP-586: GRPC Implementation for Resource Price Interfaces Aug 29, 2023
@317787106
Copy link
Contributor

317787106 commented Aug 30, 2023

@lxcmyf Good idea, it supplements the grpc api and gives more convenience to interact with java-tron. But how can you express historial prices with only one string in ResourcePricesResponseMessage? I suggest to give a struct.

@lxcmyf
Copy link
Contributor Author

lxcmyf commented Aug 30, 2023

@317787106
Good question, the return body data structure of the interface has not changed compared to before. This is an example:

{
    "prices": "0:100,1575871200000:10,1606537680000:40,1614238080000:140,1635739080000:280,1681895880000:420"
}

@L-Reid
Copy link

L-Reid commented Aug 30, 2023

I'm glad to see this, expected to all http apis have the corresponding grpc implementation.

@halibobo1205
Copy link
Contributor

+1

@Bellgin
Copy link

Bellgin commented Aug 30, 2023

Finally, these are very frequently asked and essential APIs for developers in the community.

@Ademillery
Copy link

Good job, hope that you have checked all the interfaces of java-tron and ensure all that support http calls could support gRPC calls as well.

@jwrct
Copy link
Contributor

jwrct commented Aug 31, 2023

Are there any other interfaces besides /wallet/getbandwidthprices and /wallet/getenergyprices that do not support gRPC calls? If so, is it necessary to support them?

@lxcmyf
Copy link
Contributor Author

lxcmyf commented Aug 31, 2023

This will be a process of identifying and filling gaps, and we will continue to follow up in the future.

@lxcmyf
Copy link
Contributor Author

lxcmyf commented Aug 31, 2023

I have submitted a PR regarding the implementation of this TIP, tronprotocol/java-tron#5412

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

7 participants