Is there an existing framework for building what the author proposes?
I've seen the "queue mess" architecture many times myself but it's been too embedded to easily migrate to something else.
I've seen the "queue mess" architecture many times myself but it's been too embedded to easily migrate to something else.
But I find that queues are often misunderstood/misused. You have to be careful not to use them in systems where the producer cares about the output (true story - I've had someone earnestly suggest an "ack queue," essentially implementing TCP-over-SQS), you absolutely cannot use them in latency sensitive contexts (if you need an async job pool, use a stack. Your peak load customers will thank you), and you have to be careful about idempotency, ordering, and delivery guarantees.
Also to put on my own arrogant hat, most of the time I've seen linked queues it's been better to orchestrate the system as a state machine.
I’ve long, long since given up getting the, to realize that separate build plans are only accomplishing one thing: Enabling (as in codependency) a bunch of bad, slow tests in two sections of the code to persist instead of needing to be rewritten.
This project has no proper reason to be more than a dozen modules, and we’ve spent time on tooling to reduce the burden of managing so many repos at once.
If you don’t have a small mountain of builds you have to compose, you don’t have the queuing problems that go along with them.