As a Roblox developer it is currently too hard to target a JobId to send a message to via MessagingService without bloating the payload. At present every server instance must receive a published message and the developer must check that the target JobId is in the payload so the message can be dropped for all instances except the one that should process the message.
If Roblox is able to address this issue, it would improve my development experience because it would take the burden of writing boilerplate for single-instance messaging handling off my hands as well as prevent me from bloating the payload with a JobId. Developers are granted a rather limited amount to send per message and I’d like to use it conservatively, assuming no compression applied.
The most ample use case I can think of is locking data to a session without consuming any data or memory store budget. In any small experience it’s valid to ask “why this feature when you can use a store service” but not quite for any large and data intensive experience that’s conservatively using their store budgets for more critical checkpoints for getting and setting. MessagingService allows us to build cross-experience features without any need for storage, ephemerally or permanently.
hey @colbert2677 - it’s possible to just subscribe to a queue with just the JobID as part of the name, then publish messages directly to those JobIDs (this was actually one of use cases that was in mind when designing the system). we have a dynamic limit on subscriptions based on the number of players and there is some throttling (so it can’t be spammed), but I would suggest giving something like this a try. if you already have many players/servers, then you probably won’t have a problem with the limit.
I was personally hoping not to do this since I prefer my messages to be fairly straight forward with the topic containing only exactly the data I need and not any extra identifying information. It also doesn’t particularly sit right with me to imagine that my messages will still get delivered to other instances even if I’m not subscribed to them assuming there’s some limitations on messages being received by servers though not necessarily processed (subscribed) by them.
Guess I’ll settle, thanks anyhow. I wanted to try my luck without using JobId in the topic (this was the original plan but it doesn’t look swell personally) but if this is the recommendation then I’ll stick with it.
that’s understandable. the intent of the messaging service is to be simple but really flexible with the different ways you can utilize the system without overloading or abusing the different channels and there are pros and cons to that for sure. I hope in the future we’ll have more bandwidth to upgrade the system to make it more powerful and/or offer more tools to really expand creators’ horizons.