- Yayıncı
- Tignex
- Ev
- babelqueue.com
- Durum
- SDK'lar 1.0 · SemVer kararlı
- Lisans
- MIT
Problem
Her ekosistem kuyruk problemini kendi terimleriyle çözüyor ve bedelini mesaj ödüyor. PHP'nin serialize ettiği bir job Go için okunamaz; bir Celery payload'ı Spring Boot için hiçbir şey ifade etmez. Alışılmış çözümler — telde `serialize()`, araya bir bridge servisi — bir dil tercihini lock-in'e, kuyruğu da sahibi olmayan bir çeviri katmanına dönüştürür.
Yaklaşım
BabelQueue önce zarfı tanımlar: her SDK'nın birebir aynı şekilde ürettiği ve tükettiği tek bir kanonik JSON şeması, ve sınıf adına değil URN'e göre yönlendirilen mesajlar. Bir Laravel üreticisi ile bir Go tüketicisi, aynı runtime'ı paylaştıkları için değil, spesifikasyon mesajın ne olduğunu söylediği için anlaşır.
Bugün altı SDK bu dili konuşuyor — PHP (Laravel, Symfony), Python (Celery, Django), Go (Asynq, Machinery), Node.js (BullMQ, NestJS), Java (Spring Boot) ve .NET (MassTransit) — hâlihazırda çalıştırdığınız broker'lar üzerinden: Redis, RabbitMQ, SQS, Azure Service Bus, Pulsar, Kafka ve ActiveMQ/Artemis.
Ne değildir
Yeni bir message broker değil; sidecar ya da proxy istemiyor. Framework'ünüzün job sistemini de değiştirmiyor — o sistemlerin zaten oradan oraya taşıdığı mesajın biçimi, başka bir dilin okuyabileceği şekilde yazıya dökülmüş hâli.
Sık sorulanlar
- BabelQueue message broker'ımın yerine mi geçiyor?
- Hayır. Zaten sahip olduğunuz broker üzerinde çalışan bir zarf spesifikasyonu ve SDK kümesi: Redis, RabbitMQ, SQS, Azure Service Bus, Pulsar, Kafka ya da ActiveMQ/Artemis. Servisleriniz arasına yeni bir şey kurulmuyor.
- Bugün hangi dillerin SDK'sı var?
- Altı ekosistem: PHP (Laravel, Symfony), Python (Celery, Django), Go (Asynq, Machinery), Node.js (BullMQ, NestJS), Java (Spring Boot) ve .NET (MassTransit). Her biri aynı kanonik JSON zarfını üretir ve tüketir.
- Mevcut job'larımı yeniden yazmam gerekiyor mu?
- Yalnızca sınırda. Servisin içinde job'lar framework'ünüzün tercih ettiği hâlde kalır; kanonik zarf, bir mesaj dil sınırını geçtiği yerde geçerlidir.
- Ortak bir sınıf adı olmadan mesajlar nasıl yönlendiriliyor?
- URN ile. Tam nitelikli bir PHP sınıf adı Go binary'si için hiçbir anlam taşımaz; bu yüzden mesaj kendini, iki tarafın da spesifikasyona bakarak çözebileceği bir tanımlayıcıyla adlandırır.
Tignex bünyesinde
BabelQueue, bağımsız bir açık kaynak mühendislik organizasyonu olan Tignex tarafından geliştirilir ve yayımlanır. Proje kendi adını, kimliğini ve evini korur; Tignex arkasındaki mühendisliktir.