Add blocksapi (BlocksProvider gprc service) #37
Conversation
strokovok
requested review from
vzctl,
spilin,
pustovalov,
aleksuss,
JonathanLogan,
birchmd and
kondakovdmitry
There was a problem hiding this comment.
Would it make sense to make the messages CloudEvents-compliant in advance?
Ideally I would like it to be fully compatible with Dapr:
https://docs.dapr.io/developing-applications/building-blocks/pubsub/pubsub-cloudevents/
Things I really want:
- source (which indexer/version) generated the block
- full tracing support
There was a problem hiding this comment.
Thanks for suggestion!
Would it make sense to make the messages CloudEvents-compliant in advance?
Making them CloudEvents-compliant might make sense.
Doing that in advance - no benefit that I see. Those structures are just for wire, not for storage (objects are ephemeral, not persistent); which means that we won't have to reconvert any existing objects -> adding it later will literally imply zero migration cost (especially because protobufs are both backward and forward compatible).
source (which indexer/version) generated the block
That should be solved for storage format first (now there's no such info in storage as such).
Is doable, but requires a lot of effort. Anyway, that is separate discussion.
full tracing support
Doable. But IMHO that's a separate task (requires additional research and discussion) that can be solved independently later
There was a problem hiding this comment.
The value of CloudEvents is that it is an existing standard that could be used to reduce cognitive overhead / the cost of documenting things + (potentially) some existing tools that we can reuse or even open source ourselves.
I agree that my concerns about introspection and source mapping can be solved at a later stage with zero migration cost. But these two pieces are needed for troubleshooting (which we have been struggling with) and for our investment decisions (who we hire, what services we need to fix/rewrite/optimize/etc).
What would be the timeline for these discussions?
There was a problem hiding this comment.
can be solved at a later
My point is mostly not about solving it later, but about solving it separately from this PR. Because I want to unblock work on sidecar etc ASAP
What would be the timeline for these discussions?
That should be recognized as a separate task and then assigned to somebody (or put to backlog) depending on priority I guess
This PR introduces
blocksapiprotobuf definitions (as well as golang-generation for those).Currently it contains only
BlocksProviderservice that allows to read blocks (but not write them).Introduced protobuf definitions:
types/proto/blockapiConvenient starting point:
types/proto/blockapi/services.protogodirectory is full of autogenerated code, just ignore itIn this API I tried to cover as many use-cases as I was able to think about:
I also tried my best to keep it flexible, concise and self-explanatory.
But I'm sure there will be useful suggestions, objections and other comments.
Please feel free to express them there, thank you!