search

nats-io / nats.rs

Rust client for NATS, the cloud native messaging system.
Apache License 2.0
1.03k stars 162 forks source link

Client vs Jetsream Context #1226

Closed jadamcrain closed 5 months ago

jadamcrain commented 6 months ago

Proposed change

Jetstream Context is just a thin clone-able layer on top of core Client, however, you can't access Client after you create a Context.

Even though Client is Clone, it would be nice to be not have to do so when I already have a client inside of Context.

Use case

Often, I need to access core NATS, service API, and Jetstream all within the same component.

Contribution

No response

Kinrany commented 5 months ago

Why does JetStream need a separate context, why isn't a single Client enough?

Jarema commented 5 months ago

@Kinrany it's just a struct that holds given JS context config - mainly it's domain and JS.API.prefix, as this is how you interact with JetStream. It does not have any overhead.

Kinrany commented 5 months ago

Perhaps Client could have a type state and optionally include the JS context config?

Jarema commented 5 months ago

You may want to use many (usually two) JetStream contexts with one NATS connection (in Hub & Spoke topologies), so the current approach seems most feasible.

EDIT: we also try to have some level of similarity between clients while beeing idiomatic in given ecosystem. JetStream context is one of such "orientation points" that let someone switching between clients find their way, while having different, idiomatic for given language API.

Kinrany commented 5 months ago

That makes sense, thank you!

Jarema commented 5 months ago

Great that your questions are answered! I'm closing the issue. Feel free to reopen if you think it should be discussed more.