-
Notifications
You must be signed in to change notification settings - Fork 42
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: subscribe to content topic via SDK #1823
Conversation
size-limit report 📦
|
7b2bdba
to
c4a7ad1
Compare
c4a7ad1
to
3550246
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.
i like the direction, but imo the API can be simplified
can also be tackled as a followup
happy to discuss
packages/sdk/src/content_topic.ts
Outdated
((await createLightNode({ | ||
shardInfo: { contentTopics: [contentTopic] } | ||
})) as WakuNode); |
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.
why are we typecasting the type LightNode
as WakuNode
? if there's some API we require, we can add it part of the LightNode
interface if necessary
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.
replaced with LightNode
in last commit
acb43ca
to
a5c278c
Compare
packages/sdk/src/content_topic.ts
Outdated
shardInfoToPubsubTopics | ||
} from "@waku/utils"; | ||
|
||
import { createLightNode } from "."; |
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.
nit: let's not do this kind of imports and explicitly mention source file
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.
fixed in latest commit
packages/sdk/src/content_topic.ts
Outdated
); | ||
|
||
// Ensures there is a peer. Without this condition, the subscription will fail to create. | ||
if (peer) { |
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.
If peer
is needed for this function to work - it should be mandatory parameter then
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.
updated in latest commit
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.
let's add a condition with throw
if peer is not provided as in the current state if run in vanilla JS - peer can be missed to be provided
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 don't understand -- when peer
is mandated as an arg in the function, why are we doing an if(peer)
check
re usage in vanilla js: i would not add if-elses to handle those scenarios
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.
removed the if clause in latest commit since peer is now required
@@ -0,0 +1,109 @@ | |||
import type { Multiaddr } from "@multiformats/multiaddr"; |
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 I think it is the way to go - especially considering alignment on waku-org/pm#114 (comment)
With current implementation I think the main problem is ambiguity between existing filter.subscribe
and these SDK functions.
To resolve that I think we should make these utils as close as possible to the node
object so that they are essentially properties - this way we make sure:
- they are accessible without any additional context such as import of it or knowledge of their existence;
- consumer can use filter directly as well (which can be the case if they decide to build on top of raw RFC standard);
The most straightforward way I see is to move it to core
and expose from here with additionally making a tech debt task.
Another way might be to move Waku
implementation to SDK as this is utility and does not follow any RFC thus does not belong to core
nb: created a debt
label just for that
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.
@weboko I added a new class to SDK that extends WakuNode
and gives it a function to create a subscription from a content topic. I think it makes sense to keep new, higher-level functions like this separate for now, and then decide on which can be moved inside the WakuNode
class itself.
I'm not sure if the entire WakuNode
class should be moved to sdk package just yet.
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 don't think we need to introduce another abstraction as in most cases it will be needed to subscribe by contentTopic
Considering this I would move WakuNode
all together to sdk
and use util functions in content_topic.ts
as private to WakuNode
that way we keep only one facade and have additional method on the WakuNode
to facilitate subscription by topic.
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.
@weboko Moved WakuNode
from core
to sdk
and added a function to create a subscription in latest commit
146c1f8
to
ff948fc
Compare
bf05522
to
97789c8
Compare
@@ -12,6 +7,8 @@ export { | |||
|
|||
export { utf8ToBytes, bytesToUtf8 } from "@waku/utils/bytes"; | |||
|
|||
export * from "./content_topic.js"; |
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.
nit: I don't really think we need to export 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'd rather leave it in for now just because it breaks unit tests if these functions can't be accessed from tests 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.
I think we should test the entry point API - that means node.subscribeToContentTopic
is the only thing that should be tested externally
packages/sdk/src/waku.ts
Outdated
waku: this as LightNode, | ||
peer | ||
}) | ||
)[0]; |
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.
nit: let's not do [0]
access as it is not safe
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.
updated in latest commit
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.
left last round of comments
packages/sdk/src/content_topic.ts
Outdated
); | ||
|
||
// Ensures there is a peer. Without this condition, the subscription will fail to create. | ||
if (peer) { |
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 don't understand -- when peer
is mandated as an arg in the function, why are we doing an if(peer)
check
re usage in vanilla js: i would not add if-elses to handle those scenarios
fd4d4a8
to
eb225aa
Compare
eb225aa
to
ee2d417
Compare
}) | ||
).waku; | ||
|
||
expect((waku as WakuNode).pubsubTopics).to.include(expectedPubsubTopic); |
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.
why are we having to typecast it as WakuNode
? are there any problems with implicit inference?
Problem
There is currently no simple way to create a subscription with just a content topic.
Solution
Adds SDK functions that given a content topic will create a waku node and a subscription to the provided content topic. It assumes autosharding is being used.
Notes