There’s honestly not a lot of write-ups or examples for this, a broker is usually very custom and specialized for specific tasks/processes. So in other words you need to decide and design this service yourself.
NestJS isn’t universally understood by programmers, that could bite you in the ass. Otherwise there’s not really a good standard outside bulletproof your code and ensure user error/hacks don’t break the system.
so what is the standard way of doing it using javascript if nestjs is not ?
thanks for the insights
When working with Node.JS, the development process is simplified, offering great flexibility. While there are options for better performance using lower-level languages, let’s set that aside for now. If you’re looking for a widely recognized framework, ExpressJS is a solid choice.
When it comes to communication across services, Node.JS allows you to use various protocols, not just HTTP. This flexibility enables you to tailor your communication strategy based on specific project needs. So, whether it’s HTTP, WebSocket, or other protocols, Node.JS provides the versatility to meet different requirements.
But NestJS is also built on top of Express.js, allowing a wide range of flexibility. I just want to know what is wrong with NestJS?
There’s a lot to grasp when calculating usage, I run a weight based scaling system but additionally run more workers than the core count to account for scenarios where a room may be sitting at 6 broadcasts then ramp up to 24 broadcasts 5 minutes or 6 hours later. So in situations the media server is shitting the bed or overwhelmed with broadcasts I can close off workers and re-open them later when factors loosen up.
A bit fancy but works very well, so my 4vCore you can imagine I may run 4-8 producer workers and 12+ consumer workers. Then sort automatically which worker must close.
There’s nothing wrong with NestJS, I should add it just comes down to a popularity contest. ExpressJS is commonly known and easier to get assistance with. If you like NestJS, you fully send it bud there’s no issue. Keep the code bullet proof and you be fine.
So, only popularity is a concern, right? There is no major setback or tech resistance when it comes to building a mediasoup server with NestJS?
None at all, if you can whip it up and serve it hot and fresh, send it. Mediasoup was built for Node.JS. You just may not get the full support with NestJS so you could be on your own sorting your own mess (non mediasoup related).
what would you recommend for highly scalable app ? like users upto 1 million
Money. Employees and more. That’s not an easy task, it’s truly the million dollar question/solution. 
Not easy to answer unfortunately, design carefully and test.
hey i need some reference on how to create a broker server and manage multiple mediaserver, is there any good resource ?
Running more workers than cpu cores is an interesting approach, but I see how it makes sense to be able to reduce load on a server when needed. How do you handle shutting down a worker if it has active connections on it? Do you just leave it to the client side app to automatically reconnect? Or do you have another way of passing those connections to a server with available capacity and signaling the client to make the new connection?
I’ve read your post on the weighted scaling system too, I appreciate you sharing your insights into how you manage your systems scaling. Thanks
Not really, everyone has their own style, a broker is just a manager service.
You can manually close a process or have it automated, that’d be up to your decision, maybe you’d move a room with 3 broadcasts around vs a room with 48 broadcasts/etc.
Users just receive a disconnection state as a viewer or broadcaster, the client will know it can re-attempt to broadcast and similar with views client will know to request to view stream again it’s a fast flicker.
Thanks