Vital distinction @rjdavid:
I am digging deep into BullMQ now, after wading in yesterday, moving over a large design. I will move over to the client/server/agent thread here as that progresses.
When you say “passed to Bull” then … do you have different applications which are not native Meteor applications so to speak? How many repositories is your overall implementation of Meteor if including “not client” and “not server” Bull focused instances? And how many of those do you have?
I run along the Crystal language lineage of compiled high-level OOP, and high-performance Ruby interpreters ( rubinius / jRuby before 3 ) which more or less worked to drain every iota of performance out of the container efficiently, so when going into node.js based systems I feel like I am flying a spaceship a city block. Trying to get over that feeling and be able to see the lightest possible and yet most versatile and resilient implementation. For example, down the line, I would see replacing the “agent” with Crystal if I can really get to language agnostic queues.
Pardon me for expanding the topic on this thread further but referring to another thread for reply, if you don’t mind @rjdavid. It is refreshing to hear your firm-crease take on things. Feels hardened. I anticipate focusing on this in Meteor in some form, even if it is code-back versus code-in. I feel like there is a fork in the road here on a design level, based on what really happens in the wild. That is why I ask “how many repositories do you really have” or “how many build processes” or “how many deployment processes” do you have, or is all of your “Meteor app” really one “Meteor app”