Replies: 2 comments 3 replies
-
|
Having let this simmer for the last 9 days and received one vote for "Internal queue with internal message producers and external consumers", I'd love to hear a bit more feedback on how this would look like. Concretely, would this be a AMQP-compatible setup or a custom protocol to invoke the remote cosumers/workers? AFAICT, for Rust there's https://github.com/bytebeamio/rumqtt, which sadly looks a bit stale. W/o stronger signal it feels a bit risky of maintaining my own AMQP broker. A custom protocol either through rust or via the JS runtime would be pretty straight forward but may not be what the voter had in mind. At that point it might be best to rely on a separate RabbitMQ instance to publish to from TB? 🤷♀️ This is mostly meant as an icebreaker, would love to get more input. |
Beta Was this translation helpful? Give feedback.
-
|
I'm sorry for the mistake.I hope it can support external producers and consumers.Consider this use case:using Caddy or other front-end reverse proxies to support multiple TB instances in the backend.These instances share data storage and message queues to achieve non-stop updates for core business operations. TB should be a lightweight solution.A solution based on Redis would be a good match—lightweight,simple,and easy to get started with.Both TB and Redis are known for their incredibly fast performance(I love that super-fast feeling).However,Redis lacks robust message queue management,which is where TB could play a significant role and potentially be a deciding factor for users to choose it. Additionally,as an easy-to-use and lightweight product,TB should not integrate overly complex third-party tools.Using Redis not only enables message queueing but also allows for shared caching.It's simple to install and use,making it a two-in-one solution. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi folks,
I was starting to get more serious about adding support for message queues. I've been looking at apalis, which looks like a great starting point. Anyway, there's like 50 things "support" may mean in this context and I don't feel like I have a good grasp on the use-cases y'all have. So here we are...
The way I see it right now, there's a few questions I'd like to answer based on your use-cases:
I'll start by sharing some inclinations:
Initially I thought the answer to (1) should certainly be internal clearly in line with the single-executable mantra but depending on peoples needs, coupling and pre-existing setups it may not be as clear cut as I initially thought.
For (2) and (3) I'm leaning internal only, at least as a starting point also letting folks implement whatever they need w/o having to provide full AMQP (or similar) support.
For (4) I'm leaning no and more towards providing abstractions that makes it easier to do it yourself with internal workers. I also don't see to much precedent for this with other queues. Thinking about examples it's also not clear to me how useful it would be. For example, sending an email probably wouldn't need a back-channel it's only success/fail. Alternatively, running post-processing or image recognition over an uploaded image would probably write the results back to blob storage or primary table respectively.
I can be haggled with and thanks already for any input 🙏
7 votes ·
Beta Was this translation helpful? Give feedback.
All reactions