The current client model, which creates a Publisher for each topic Publisher.defaultBuilder("TOPIC_NAME"), which becomes a bit prohibitive in use cases where the consumers could publish messages to multiple topics.
In that scenario we would need to create one publisher for each topic, and since those publishers seem to consume some resources (like connections to the server) we could end up with unbounded number of those objects lying around.
What's odd is that the gRPC api that is defined for pubsub actually does not follow this pattern since one could have different PublishRequests objects while sending to the server.
Other brokers such as Kafka or RabbitMQ allows users to specify topics or exchanges just as simple Strings while the publisher that has the connection factory is shared amongst users of the library.
Such model would help us designing a more intuitive Spring MessagingTemplate for google pubsub as we would not need to take care of the control of Publisher instances
The current client model, which creates a Publisher for each topic
Publisher.defaultBuilder("TOPIC_NAME"), which becomes a bit prohibitive in use cases where the consumers could publish messages to multiple topics.In that scenario we would need to create one publisher for each topic, and since those publishers seem to consume some resources (like connections to the server) we could end up with unbounded number of those objects lying around.
What's odd is that the gRPC api that is defined for pubsub actually does not follow this pattern since one could have different PublishRequests objects while sending to the server.
Other brokers such as Kafka or RabbitMQ allows users to specify topics or exchanges just as simple Strings while the publisher that has the connection factory is shared amongst users of the library.
Such model would help us designing a more intuitive Spring MessagingTemplate for google pubsub as we would not need to take care of the control of Publisher instances