Closed corpix closed 6 years ago
Consumer can connect to multiple nsqd, and it can re-connect after disconnection from an nsqd. Consumer can be instructed to connect to nsqlookupd instead, in which case it looks up the topic in nsqlookupd, and then connects to all the returned nsqd, and the re-connect logic is different. The topic and channel are sort of part of the protocol connection handshake.
The thing which does not know how to connect to nsqd is the handler function - that's the simple dumb consumer. The Consumer is the sophisticated connection handler. And multiple instances of the handler function can be run concurrently if max_in_flight > 1.
So, there are some good reasons why the current API design is the way it is, and it's unlikely we would change it because that would break compatibility with lots of current users. If you feel strongly, however, you could try to write your own competing "simpler" nsq client library for go, and some people might try it.
Ah, okay, I see things strongly relates on each other. Probably I'll try to create my own package if I have much time. Love NSQ, it is so simple to use <3 Thank you for the answer!
Hello. Why do you have
Consumer
connecting to NSQ?Let me provide some examples. Current implementation forces me to use consumer in this manner:
But I think that
Consumer
should not know ho to connect to NSQ. It's just a dumb consumer, it should have single responsibility - consume data! From my point of view using aConsumer
should look like this:I think this would make client library more easy to use, more testable, etc.
What do you think about this?