2018-02-20 Meeting notes: Plans for implementation of RChain API using JSON

2018-02-20 Meeting notes: Plans for implementation of RChain API using JSON

Date

Feb 20, 2018

Attendees

  • @Kelly Foster

  • @Medha Parlikar (Unlicensed)

  • @Chris Kirkwood-Watts

  • @Nash Foster

Goals

  • We will use this time to address questions Nash has about the intended use of JSON as  documented here, and to

  • Discuss next steps for moving to a Protobuff solution. 

Discussion items

Time

Item

Who

Notes

Time

Item

Who

Notes

10 min

Current status of the API

@Chris Kirkwood-Watts

  • What is in his plan

  • Implemented

    • Server

    • Marshalling

  • Imagined

    • Ports

    • Route

 

Lykka requirement

 

  • They want us to implement a small api.  Get transaction, captured in the doc that Greg sent. 

  • it's a JSON ish thing.

  • Lykka's document seems not very 'professional' - they may have a higher tolerance for dealing with the churn in JSON.  Low expectations of quality.

 

Meta mask requirements

 

  • The MetaMask guys are wanting a specific API - Chris is feeling that the JSON RPC API is the most standard one out there.

  • What ETH made difficult, getting the true state of the chain without running a node. They had to pull in all the headers and the chain outline.  No light client.  Wound up querying their own servers to obtain the state.

  • Any complaints with versioning issues?  Not according to Chris.

 20

 How we get to a Protobuf implementation of the API

 Everyone

  • Write a nice protobuf API that everyone can use.

    • Will have to have the largest surface area.  Every bit of data you need has to be exposed.

  • For each Key implementation, write a REST API in Python (no type safety possible - and it's fast).

    • little HTTP servers that take the Protocol buffer output and pass it to a REST API.

  • Concerns around level of effort - JSON is fast and easy. 

  •  

  • Or should we use Thrift? Nash is not opposed to this.

  • DECISIONS

    • Going forward, prioritize implementation of Protobuf solution, over JSON or other solutions other groups might want.

    • Implement a GRPC Protobuf solution as the base Node API

    • Nash approves including the work done to-date on the JSON RPC in the 15 March release

    • Streaming data via Protobufs isn't perfect, and we may need to perform low level optimizations.

      • How do we expose the storage log in an API for the 3/15 release?  

Action items

@Chris Kirkwood-Watts issue PR for JSON RPC in the next two days
@Chris Kirkwood-Watts look at Protobufs GRPC to write the base of all API's - if that is good
@Chris Kirkwood-Watts take the JSON RPC stuff and make it a consumer of the GRPC stuff
@Chris Kirkwood-Watts Instrument monitoring with Prometheus, demonstrate some things internally
@Chris Kirkwood-Watts instrument Grafana on top of Prometheus and write up a how-to document for the development team to use - so they can look at metrics
@Chris Kirkwood-Watts document how to expose metrics to the Node API. As a rule we choose metrics instead of logging.
@Medha Parlikar (Unlicensed) create epics and tickets for Protobufs and GRPC work
@Medha Parlikar (Unlicensed) update Node specifications with outcomes from this meeting