-
Notifications
You must be signed in to change notification settings - Fork 411
Expose RpcClient and RestClient interfaces as pub #825
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
Expose RpcClient and RestClient interfaces as pub #825
Conversation
Useful for use outside of the BlockSource context, e.g., when implementing fee estimation or transaction broadcasting.
Codecov Report
@@ Coverage Diff @@
## main #825 +/- ##
=======================================
Coverage 90.97% 90.97%
=======================================
Files 48 48
Lines 26452 26452
=======================================
Hits 24064 24064
Misses 2388 2388
Continue to review full report at Codecov.
|
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.
LGTM
Hm I'm sorry if I should've tested this earlier, but this is giving me this error: https://i.imgur.com/kmRusav.png |
The API needs a concrete type Otherwise, if you need to work with a complex JSON response, then you'll have to define a |
I do have to get complex structs sometimes. I think I'd prefer to do the more flexible approach (i.e. |
Changes shouldn't have to be upstreamed to The question is really around data abstraction and encapsulation. The API was design such that anyone can write a conversion function to use with it. So you can simply define a small struct |
OK, I see. I was hoping to make the each sample node portion concise enough to include directly in the guide, but with adding this conversion boilerplate it isn't really nearly as concise. So, just wanted to point that out as a bit of a downside. I agree it encapsulates the conversion logic but I don't think it increases the readability tooo much, kinda confuses it a bit since you have to parse the |
The answer is always more abstraction. :) Rather than have |
I think it's nice when everything the user needs is right there in a code sample in the guide and avoid abstraction layers (which don't add very much, imo) altogether. In my mind, the sample's being made to be married to the docs, so it's being made so self-contained snippets can be pulled out. I think a more production node would indeed have these helpers you mention. Edit: or rather, the abstraction layers would usually add value, but in this case I think it detracts more. |
Hmmm... I'd imagine we'd only want to repeat small snippets of the sample in the guide and link to the sample repo where necessary to see more details. Utilizing layers of abstraction allows us to do that while eliding details that could distract from the overall purpose of the guide: demonstrating how to set up a Lightning node using LDK. Those details are an exercise for the reader either by writing the code on their own or peeking at the solution (i.e., the sample node repo). |
Useful for use outside of the BlockSource context, e.g., when implementing fee estimation or transaction broadcasting.