Json-server: 404 if another process is started on the same port

[kamiranoff]

I followed the simple example with a db.json and ran json-server --watch db.json. Everything seemed to work fine but I ran into 404s when trying to access any route (ie: http://localhost:3000).

Turns out I had another process running on port 3000.

The console did not throw any error though.

[jacobwarduk]

A few of our testers at work have been running into this 'problem'.

If @typicode labels this as something that needs to be worked on then I'd be happy to pick it up.

[jessycormier]

Why not just change the default port so you stop running into this conflict?

json-server --watch --port 3200 db.json

[jacobwarduk]

@jessycormier so what if 3200 is taken too? And do we have to keep changing the port our application is requesting every time we change the port of the json-server?

[jessycormier]

@jacobwarduk while I do agree that the console should at least warn us there is already something using this port I think choosing a random port between 1-65535 should be easy enough so we have no conflicts.

Having the error/warning would be useful for sure though. For example if you run BrowserSync and json-server, they both work on the same port and they'll both try and server you files on that same port but things act very strange and no warning is given.

Hence my solution given to you. I run BrowserSync on port 3002 (its ui on 3001) and json-server on 3100 to remove the conflicts. not ideal but it works for now. (for me)

--edit typo

[jacobwarduk]

@jessycormier

Having the error/warning would be useful for sure though.

So you agree, yes?

For example if you run BrowserSync and json-server, they both work on the same port and they'll both try and server you files on that same port but things act very strange and no warning is given.

So we should show come sort of error, yes?

Hence my solution given to you. I run BrowserSync on port 3002 (its ui on 3001) and json-server on 3100 to remove the conflicts.

Your "solution" is not a solution to the problem. That's fantastic that you know you are running BrowserSync on port 3002, it's UI on 3001, and json-server on 3100, but that is not an accurate representation of how everybody works - or even uses json-server.

no ideal but it works for now.

So, why can't we at least try to make it closer to ideal?

Myself: I use it for mocking out a backend while I'm doing UI work. I have my web server running on 8181 and my json-server on 3000. Sometimes I'll start getting 404s, I'll switch through my tabs and find that I have multiple instances running or that something else has decided to start running on that port.

Our automated UI testers: Their tests spin up a new json-server for each test and tear it down before the next one. Occasionally one instance may not get killed off - for whatever reason - no warning, other than their tests keep running and failing!

[jacobwarduk]

If something else is running on a specific port used by a cli app, most others (that I've come across) either:

• Error out and tell you that something else is blocking the port it wishes to use.
• Increment the port number and try again (repeat until success).

Either of these seem like reasonable approaches, with the second being my preference.

[jessycormier]

@jacobwarduk Just trying to provide a solution as I didn't know your environment/setup :)