-
Notifications
You must be signed in to change notification settings - Fork 919
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
feat!(api/rpc
): OpenRPC scaffolding, migrating OpenAPI gateway to api/gateway
#1175
Conversation
ac420e0
to
5289813
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
needs some godoc and format but otherwise looks good already.
bb75532
to
3d4c417
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RPC is not a module and should not have nodebuilder
. It's like commands, config, or flags of each module. Each module has an API and each module can be accessed through RPC.
If the RPC server is provided to DI, each module should register its handler there, not some high-level module or API importing it and registering handlers manually. This is something that should be done in this or other RPC related PR and not deferred to some later refactorings.
Gateway though could be a module.
I disagree here. The RPC is a service that is running for the lifecycle of the node, and accesses the other modules - just like the other services. I do not understand the comparison with commands, config, or flags. Generally, by letting each module be in charge of registering itself on the RPC server, it will no longer be possible to see at a glance which APIs the RPC is exposing. More importantly, this clearly leads to higher coupling (of the individual modules to the RPC) and lower cohesion (inside the individual nodebuilder modules, since they now have to register on an RPC). I can explain this and the consequences more in depth if you disagree. |
@Wondertan I think rpc warrants its own fx.Module -- it is not one of our "Modules" offered by node per-se but I would consider it a module in our software. I am, however, okay with each module registering its own endpoint on RPC, but I don't really see the added benefit rn. |
3d4c417
to
8da910f
Compare
8da910f
to
5dec0ba
Compare
Codecov Report
@@ Coverage Diff @@
## main #1175 +/- ##
==========================================
- Coverage 56.34% 55.62% -0.73%
==========================================
Files 160 162 +2
Lines 9935 9981 +46
==========================================
- Hits 5598 5552 -46
- Misses 3783 3876 +93
+ Partials 554 553 -1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- // rpc components
RPCServer *rpc.Server // not optional
I think each module should expose / return |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After plenty of discussions, we(@distractedm1nd, @renaynay, @vgonkivs, and @Wondertan) agreed on this approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lfg
…pi/gateway` (celestiaorg#1175) Based on celestiaorg#1056
…pi/gateway` (celestiaorg#1175) Based on celestiaorg#1056
…pi/gateway` (celestiaorg#1175) Based on celestiaorg#1056
api/rpc
): OpenRPC scaffolding, migrating OpenAPI gateway to api/gateway
api/rpc
): OpenRPC scaffolding, migrating OpenAPI gateway to api/gateway
Based on #1056
api/gateway
. This is no longer bundled with the node as of right now./service
directoryapi/rpc
nodebuilder/rpc
(no more cyclical dependency problem)I would suggest reintroducing the gateway, with an additional config and a default "off" mode, should be done in a different PR.