Nest: Allow for Microservices to bind on random port

[jmcdo29]

Feature Request

Allow for microservices to be started on port 0 to allow for dynamically finding an open port

Is your feature request related to a problem? Please describe.

I ran into this while working on a testing suite for a library. For HTTP, GraphQL, and Websockets, I'm able to pass app.listen(0) and get the server started on a random port (which can then be found with await app.getUrl()), but with microservices this isn't possible. I believe this funciton is the reason why, as a 0 appears falsy in JavaScript, and thus will use the fallback value (3000 in the case of TCP).

Describe the solution you'd like

If we could check the validity of the returned value, or possibly change from using || to ?? so that in the event of 0 we don't use the fallback value. I'd be willing to work on this and figure out a solution.

Teachability, Documentation, Adoption, Migration Strategy

Shouldn't really be a problem, most people probably aren't making use of this behavior anyways.

What is the motivation / use case for changing the behavior?

It would make for easier testing when it comes to setting up servers without knowing what port, especially useful for CI situations. Plus, it would then act like HTTP, GQL, and WS applications.

[kamilmysliwiec]

Sounds good! Would you like to create a PR for this?

[jmcdo29]

I'll definitely look into if this is actually possible. In my tests I was having trouble getting it to work properly, but I'll see what I can do 😸

[hood]

I'm not sure that getOptionsProp() is the culprit. It should return 0 as expected if 0 is passed as the port.

[jmcdo29]

@0xCAP you're right. This function however, would be a culprit of the issue, as if a 0 is returned, being a falsy value, JavaScript will end up taking the default value (3000)

[hood]

I have a fix for this issue ready. I'm trying to figure out a proper test for the scenario then I can submit the PR.

[underfisk]

@jmcdo29 The challenge I would present you is what if that port is already assigned to a process running inside a container? Recently I've had few problems that my nest application was running 2x in the same port, one inside the docker container and the other outside but both having the same network bridge which kinda made one of the apps stop serving.
I know this isn't a big deal but since nest can run with the port already being used Ii assume assigning a random port might bring some issues (or not).
Anyway the feature request is awesome and i would like to see that

[jmcdo29]

@underfisk when assigning to port 0, it should be the operating system's job to determine what port to truly run on. So in theory, you could start up on any port in Docker and expose it, and the exposed port that Docker connects to _should_ be taken up and the OS should know not to bind to it. Though, you bring up an interesting point and I'd love to dig more into that here soon

[underfisk]

@jmcdo29 I agree with you and I've used port(0) but i think the point here is what if docker port is not exposed but you can access the same network adapter.
I'm not sure yet but I've seen it giving me troubles already by silently using the same port and booting both apps, you can try locally using a docker container and bind the same port as you external application and both will start but only one of them will serve or none as it happens to me.
The pull I open to @kamilmysliwiec was about duplicated HTTP controller route but indeed the main issue was the same port being used by two different processes and the app simply dangles

[Rapliangle]

hi,there. I have the same question with docker. Is there any good solution already to bind a dynamic port?