Update: Within two months of feverish writing, I have come to the conclusion that writing NSQ apps is relatively easy for the developer. It dawned on me that the real meat of the issue is about distributed system. In short, this project is deprecated in favor of the IrisMQ Guide which is available at github.com/irismq.
NOTE: Basic examples can be found at https://github.com/itmarketplace/go-queue/tree/master/examples
A note from Mitchell Harper struck a chord with me regarding marketing and product.
To quote him,
Marketing is equally as important as product.
This is what NSQ, a realtime distributed messaging platform, needs in the sea of message queue (broker-based, brokerless and anything in between).
This open source software should be the foundation of your microservices framework.
Because it is a hallmark of usability and it just works. And it is agnostic to Web frameworks, programming languages and libraries.
As I have said before, microservices start where Web services end.
This is how software should work. You can use anything you like but the message queue-based pattern remains.
To summarize courtesy of Ivan Dwyer:
Web services (app-centric)
- real-time requests (user-facing)
- how does it run? (synchronous)
- how is it deployed? (Web server)
- how is it invoked? (request/response)
- how is it routed? (load balancer)
- how does it fail? (reroute)
- how does it scale? (more Web app servers)
- how does it execute? (long-running)
- how does it get data? (database)
- how is it implemented? (API)
- background processes
- how does it run? (asynchronous)
- how is it deployed? (Message queue)
- how is it invoked? (event, publish/subscribe)
- how is it routed? (queue)
- how does it fail? (retry)
- how does it scale? (more workers)
- how does it get data? (payload)
- how does it execute? (ephemeral, start – stop)
- how is it implemented? (Message queue clients)
Stay tuned. Reply to this post or tweet me @ibm2100 for updates.