Developer Access to the Libra Blockchain

Validators currently expose a gRPC endpoint for clients to access the Libra blockchain, and the Libra Core team is interested in receiving feedback from the developer community about gRPC. For example, is gRPC easy to work with? Would you prefer JSON-RPC, REST, or something completely different? What APIs would be valuable for your use case? What API endpoints have been valuable in other blockchain projects?

Please provide your feedback and let us know 1) which API protocol you would like an endpoint on nodes and 2) what use cases you are trying to support. Thank you for your input and we hope to learn more about how to serve the community!

9 Likes

1 ) Yes it’s ok to work with gRPC because some people start programming Framework to easily interact with Libra node :

  1. For the moment possible interactions with the node are very limited, but will be great to have API with some functionalities like :
  • getaccountstate or balance
  • mintLibra
  • transferLibra
  • createaccount
6 Likes

We have build a python library and a restfual API. If the libra core team is going to develop officail rest api and offical programming Framework, please anounce in advance.

This allows me to stop developing lib and rest apis and move on to upper level development.

If libra testnet support publish and execute smart contract, we don’t need to build our own dev network.

4 Likes

yes, IMHO, an official framework plus support docs would be probably helpful for those like me who’re relatively new in blockchain space .

2 Likes
  1. We like working with gRPC. The combination with proto files works. But documentation could be improved and it might be handy that proto files live in one folder. Would we prefer rest? Not really.

  2. Current available API endpoints are sufficient for our wallet use case. Maybe the limit of 1000 for transaction ranges could be increased to 5k. Its a bottleneck in our setup.

3 Likes

Thank you for your feedback! Why do you say you would not prefer REST?

1 Like

gRPC performs and gRPC is a more modern protocol.

2 Likes

Frankly speaking, I’d prefer REST because it sounds a little more familiar to me. :slightly_smiling_face:
However, it might have both its pros and cons.

I’d be grateful if you guys let me know in advance because i was thinking to create rest API for the locals in Japan as a monetization API scenario.

4 Likes

Rest api and grpc. While grpc is more “efficient”, rest APIs are easier to visualize and consume. Also agree on allowing an upper limit of above 1k for developers access.

4 Likes

What are your use cases for bulk querying? Curious to see if this is a big use case.

I believe you have probably compared these already when deciding on gRPC. Of course rest would be the most simple for anyone to start using and could be easilly integrated to various platforms but gRPC has features that make it better in this case.

For example streaming. Libra could provide a streaming api which I could use to listen to events on an account and I would not need to poll the api, also from client side I could open a stream for making payments instead of creating a new request for each transaction.

Also, I believe gRPC is more efficient on resources. Libra is already optimizing the request and response payloads by cutting away of bytes here and there, you could not do that with a verbose rest api.

To sum up, the current api does not utilize all the potential it has, when it does, gRPC will be a better choice than the others mentioned.

1 Like

for a blockexplorer :slight_smile:

2 Likes

Indeef. Blockexplorer and everything related. Including wallets :slight_smile:

2 Likes

A primary use case I can think of is only a micropayment system like alipay in China which consumers can use libra to pay at merchants.

I just want to know of opinion from others, too . :thinking: :face_with_hand_over_mouth:

2 Likes

Ah, please don’t choose the easy road now, you started already fine, switching to REST would be surrendering to the easy path.
gRPC was a very valid choice for this use case, JSON-RPC would also be fine as eg. Ethereum chose, but gRPC is even better in terms of support and wide-spread usage. REST would be the wrong choice for sure. Yes, it’s so easy to use and there are so much tools and Swagger and Postman and client generating frameworks - all true, but

RESTful Web services allow the requesting systems to access and manipulate textual representations of Web resources by using a uniform and predefined set of stateless operations.
(Wikipedia)

there are no resources here. Yes, it’s easy to redefine everything to a resource and many did, but for what happens in those clients, to me it’s RPC. And if it’s RPC, it shouldn’t be RESTified just for the sake of ease of access, please stay with gRPC!

2 Likes

Coming from the Ethereum community and progressing with the API endpoints that web3.js has been providing - I’d say the most important thing to be provided is a “transaction status” promise that returns “pending” , “error: message” , or “success: tx hash” - as this has major UX implications for projects built on top.

The second thing is to keep as low level functions open in the tx lifecycle so that developers have the flexibility to develop applications that pay for user transaction fees - this is VERY important.

REST should be developed - it’s the easiest to develop around for all developers and not just core developers. A block explorer would also be very helpful and, lastly, and ode editor UI (GUI) for smart contract deployment (like Mist for example).

2 Likes
  1. Considering the most common issue of creating a mass critical developer community I would implement a JSON-RPC because it’s widely used in the crypto space (this is to increase adoption not considering technical aspects). However, I don’t see any impediment using gRPC really.
  2. In our case we are building a voting platfom.
  3. We do need more RPC methods available like sendRawTransaction() to interact with our smart contracts.
1 Like
  1. Add REST API - This is why
    I think that if we want to drive adoption and expand the audience of Libra beyond Core developers working with Blockchain or Cryptocurrencies, then Libra should also provide a REST API.
    REST API not only have a healthy and big community of Developers, iPaaS, vendors, OpenAPI supporter, but also a solid understanding from Business involved in API Economy, API ecosystems and Digital Transformation.

  2. Use Case
    I’m Integration Architect working with Mulesoft solution. Currently, developing (actually evaluating it) a custom Libra connector for Mule that would make possible integration with other REST API based services. The Libra connector basically would abstract away the gRPC for Mule Apps.

2 Likes