Pitch: O desafio de abstrair filas sem esconder o comportamento de cada provider · sousadiego11

Quando comecei o EasyQueue, achei que a parte difícil seria criar uma API única para diferentes sistemas de mensageria.

Na prática, essa foi a parte fácil.

O verdadeiro desafio foi manter uma interface consistente sem fingir que todos os brokers funcionam da mesma forma.

Por exemplo:

RabbitMQ trabalha com acknowledgements e requeue.
Amazon SQS utiliza visibility timeout.
Redis Streams possui consumer groups e pending entries.
Azure Service Bus traz conceitos como PeekLock e Dead Letter Queue.
NATS JetStream possui seu próprio modelo de streams, consumers e acknowledgements.

Todos resolvem o mesmo problema: entregar mensagens.

Mas cada um possui garantias, limitações e comportamentos diferentes.

Foi aí que percebi que uma boa abstração não é aquela que esconde todas as diferenças.

Ela é aquela que deixa o código da aplicação simples, mas ainda permite aproveitar as características específicas de cada provider quando necessário.

Foi esse princípio que guiou a nova versão do EasyQueue, que agora suporta:

Ainda há bastante trabalho pela frente, mas tem sido um ótimo exercício para entender melhor os trade-offs entre diferentes sistemas de mensageria.

Se você já precisou trocar de broker ou manter suporte a mais de um provider, como resolveu esse problema?

#opensource #nodejs #typescript #backend #softwarearchitecture #messaging #rabbitmq #redis #nats #azureservicebus