-
Notifications
You must be signed in to change notification settings - Fork 132
taprpc: extract as standalone Go submodule for WASM clients #1487
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
Conversation
This is a minimal replacement of #1090 |
Pull Request Test Coverage Report for Build 14789890974Details
💛 - Coveralls |
4c0d4da
to
e87609b
Compare
Overall plan: lightninglabs/lightning-node-connect#113 (comment) |
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.
Thanks for looking into this!
Looks pretty good, but have a couple of suggestions.
@@ -20,7 +20,10 @@ require ( | |||
dario.cat/mergo v1.0.1 // indirect | |||
github.com/Azure/go-ansiterm v0.0.0-20230124172434-306776ec8161 // indirect | |||
github.com/Microsoft/go-winio v0.6.1 // indirect | |||
github.com/NebulousLabs/fastrand v0.0.0-20181203155948-6fb6489aac4e // indirect |
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.
While we're at it: can we please replace the github.com/lightninglabs/taproot-assets => ../../../
at the top with a fixed version so we don't have to update these two files with almost every PR?
I know it risks us forgetting to update it if we ever actually change anything that impacts the example. But the number of force pushes and CI cycles that can be avoided by forgetting to update these two files IMO is worth it.
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.
I've pinned to the latest main
commit of taproot-assets for now because that was the easiest to build. Once the next release is out, I will pin to that. See commit message for more. Let me know if there's a better strategy.
@@ -1,17 +1,18 @@ | |||
package priceoraclerpc | |||
package rpcutils |
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.
Same as my previous comment, this would IMO better fit in the oracle
package.
// UnmarshalFixedPoint converts an RPC FixedPoint to a BigIntFixedPoint. | ||
func UnmarshalFixedPoint(fp *FixedPoint) (*rfqmath.BigIntFixedPoint, error) { | ||
// UnmarshalRfqFixedPoint converts an RPC FixedPoint to a BigIntFixedPoint. | ||
func UnmarshalRfqFixedPoint(fp *rfqrpc.FixedPoint) (*rfqmath.BigIntFixedPoint, |
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.
Looking at my previously proposed rule "put these functions into the package that defines the non-RPC type" should perhaps be a soft rule or "rule of thumb". Don't think placing this in the rfqmath
package makes that much sense. But IMO it definitely makes sense in the rfq
package.
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.
Overall concept ACK.
No strong feelings on if we go with the rpcutil
package vs putting RPC serialization routines in select packages. The main pitfall to avoid as mentioned is taking care to not introduce circular dep cycles.
If main
is the only package that imports this new one, then we should be ok. However if any other package imports it, then it'll likely be easy to run into a circular dep.
e87609b
to
d68e675
Compare
Which might be useful for outside developers. And also slim down For example:
|
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.
Nice, LGTM 🎉 (pending green CI which can be achieved through rebasing).
Ideally, we would pin to a stable release of taproot-assets, as this is more useful for developers. However, release v0.5.1-alpha introduces logging changes that complicate integration. For now, we pin to the latest `main` commit and will update to the next stable release once it's available.
Rebasing... |
Our overall goal is to make taprpc as lean as possible so that it is not dependent on the rest of the `taproot-assets` module. Taprpc will then be made into a module that can be imported for lean WASM builds. With that in mind, we move gRPC marshalling functionality from the taprpc package to a new package called rpcutils.
Move price oracle related gRPC marshalling functionality from the taprpc package to the rpcutils package as preparation for future modularization.
Move RFQ related gRPC marshalling functionality from the taprpc package to the rpcutils package as preparation for future modularization.
Needs another rebase? |
Looks like we still have some marshaling code here: https://github.com/lightninglabs/taproot-assets/blob/1741fd4a0e9ad57b7cbad33cc4235fb795f221db/taprpc/universerpc/marshal.go Or is that intended? |
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 🥦
Only comment is if we want to move over this marshal code into the new package created: https://github.com/lightninglabs/taproot-assets/blob/1741fd4a0e9ad57b7cbad33cc4235fb795f221db/taprpc/universerpc/marshal.go
Move universe related gRPC marshalling functionality from the taprpc package to the rpcutils package as preparation for future modularization.
I've moved those marshalling functions into |
Convert taprpc into a separate Go module. This change allows WASM clients to depend only on this smaller module, avoiding the need to import all exported symbols from the taproot-assets package.
The Lightning Node Connect WASM client requires access to `perms.go` for RPC endpoint-related permissions. We move it into taprpc so that the WASM build only needs to depend on the taprpc module, without importing the entire taproot-assets module.
I pushed up a fix to the module creation commit and bumped some dependency versions. This removed the diff in the generated RPC code and should also prevent Dependabot to go crazy after we merge the PR. |
Reformulate
taprpc
as a standalone Go submodule. This allows WASM clients to depend on a smaller, more focused module, rather than importing the entiretaproot-assets
package.Related issue: lightninglabs/lightning-node-connect#113
Overall plan: lightninglabs/lightning-node-connect#113 (comment)