Skip to content

Refactor Publish/Subscribe/Serve to be more flexible #12

@foxis

Description

@foxis

Right now we have Subscribe/SubscribeTo as well as Publish/PublishTo methods.
With the introduction of JetStream it appears that sometimes a service wants to consume existing stream(e.g. one created via cli or other automation tools on the account-level) without registering it. Also, the Service API will be much cleaner with this change.

This can be achieved by adding options to Subscribe method related to JetStream, however, the best way would be to refactor Subscribe/Publish so that this is possible:

  // Subscribe as usual to prefix.name.token1.token2
  service.Subscribe(handler, "token1", "token2")

 // Subscribe as usual but with JetStream
 service.Subscribe(handler, "token1", "token2", WithStream(streamId, consumerId))

  // Subscribe to "my_prefix.my_name.token" similar as SubscribeTo does and use a group name
  service.Subscribe(handler, Subject("my_prefix.my_name", "token"), WithGroup("my_cluster"))

Similarly service.Publish would accept options instead of subject tokens.
This will allow to get rid of SubscribeTo/PublishTo methods and will allow to easily expand the functionality of these methods, e.g.

  // Encrypt for specific recepient
  service.Publish(data, Subject("prefix.name.token"), WithEncryption(dst_public_key))

  // send an encrypted Request to some subject and accept at least 50 messages. The response is expected to be encrypted also,
  // but it depends on the responder
  service.Request(ctx, data, &resp, Subject(...), WithEncryption(dst_public_key), WithStream(resp_builder, resp_chan), WithStreamLimit(50))

The change should not break existing users and should mark SubscribeTo/PublishTo as deprecated.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions