We Keep Coding

nuxt.js - unable to define host and port

nuxt.js always defaults to localhost despite host being defined as frontend.gradez.loc in nuxt.config.js
Contents of nuxt.config.js:
server: {
host: 'frontend.gradez.loc',
port: 3000
},
Contents of package.json:
"config": {
"nuxt": {
"host": "frontend.gradez.loc",
"port": "3000"
}
}
nuxt launch script as dev:
"dev": "nuxt --hostname frontend.gradez.loc --port 3000",
For some odd reason when starting the development script it always defaults to: Listening on: http://localhost:3000/
I tried to do exactly the same on react and the only thing I had to do was create a .env file and inside it I added host=frontend.gradez.loc and it worked just like that.

To create your server, under the hood Nuxt uses Node's http.createServer, then calls listen({ host, port }) on that server.
So if on your local machine the hostname frontend.gradez.loc is mapped to 127.0.0.1, which I assume is the case, then that server is running on the IP 127.0.0.1.
To create the url you see printed in Listening on..., Nuxt gets the IP of that underlying server, and maps it back to a hostname string. It statically maps the IP 127.0.0.1 to the string 'localhost', so no matter what host you configure, if it maps to 127.0.0.1 then Nuxt will always map that to localhost in that url. The code that does this is here.
There's nothing incorrect per-se about reporting the server is running on localhost:3000 rather than frontend.gradez.loc:3000. It's literally true, in a networking sense, because both ultimately point to 127.0.0.1:3000. So nothing is broken here from the perspective of the dev server, it's working as designed.
I'm not sure if you have anything automatically loading that url in the browser when you start the server - if so I can see how this is inconvenient from the perspective of other things in your workflow coupled to that hostname such as cookies, proxy servers etc - but if you manually type frontend.gradez.loc:3000 into your browser everything will just work.

Node.js WebStorm remote debugging not working (without SSH tunnel)

I'm trying to debug on a live server running a Node.js webserver (Express, TypeScript).
I run the node server with NODE_ENV=development node --inspect=9229 --inspect-brk build/start.js, and it says it's waiting and listening (Debugger listening on ws://127.0.0.1:9229/a61485f2-aef8-4719-901d-4d5ad9d1e6cd).
I set up an SSH tunnel (using this method: https://gist.github.com/pajtai/081e0371e7366c79c0b9), and I set up an "Attach to Node.js/Chrome" debug configuration, with Host: localhost and Port: 9229. Then when I hit the debug button, it connects through the SSH tunnel, and the node.js process runs just fine, stopping and debugging at all my breakpoints.
However, when I don't set up the SSH tunnel, start the node server the same way, and set up an "Attach to Node.js/Chrome" profile with the host as the URL or IP of the server, WebStorm can never connect. There is a little red bubble over the "5: Debug" icon at the bottom saying it can't connect, and sometimes it says "Closed Explicitly". I have opened up port 9229 in the firewall settings for the server (I've tried TCP and UDP).
What am I doing wrong? Please help, anyone!
I'm using Mac OS X 10.15.3 and WebStorm 2019.3.1.

Node binds to localhost by default and thus can't be accessed from outside unless you set up the port forwarding (via ssh tunneling, for example).
You can try changing the command to node --inspect-brk=0.0.0.0:9229 build/start.js - does it help?
Note that Node.js discourages using remote debugging in this way: https://nodejs.org/en/docs/guides/debugging-getting-started/#enabling-remote-debugging-scenarios. Using SSH tunneling is recommended

deploying node add on server without using localhost

I have a node app that I am trying to deploy on my server. I have an index.html file in a public folder and an app.js file. If I navigate to the project in the command line and run node app.js it runs the app on localhost:8888 and shows the index.html file.
Now that I have uploaded this to my server I am wondering what I need to do, and change (if anything) in my app.js file so that i can visit the site without visiting localhost:8888, but instead the actual url.
I have tried http://162.xx.xxx.xxx/folderName/app/public:8888, but this doesn't work.
var express = require('express')
var app = express();
app.use(express.static(__dirname + '/public'))
app.get('/', function (req, res) {
res.send('Hello World!')
})
app.listen(8888, function () {
console.log('Example app listening on port 8888!')
});

"Server" is a word with two primary meanings in software development.
It can mean either "A piece of software that listens on a network" or "A computer running that kind of software".
So having uploaded the JavaScript program to the remote computer that is your server you need to do exactly the same as you did on your own computer.
i.e. you need to get a terminal on the server and run node app.js
It will then be available at http://your.example.com:8888/
(More advanced uses would involve using software like forever or system.d to run it automatically as a background process).
If you were using the term server with the other meaning (i.e. you mean "Apache HTTP" or "IIS" or similar), then you are out of luck.
Using Node for server side code means running a server written in JavaScript.
To use this in combination with something like Apache, you would either:
Run the Node server instead of Apache
Run the Node server on a different port and point some services at that port explicitly
Run the Node server on a different port and use something like ProxyPass to have Apache relay requests to it

Change the port number from 8888 to 80 and then use the address of your server in the browser. For example, "mysite.com" for a domain name or "123.45.678" for an IP address.
If there are other sites on that server, you can't run it on port 80. (Port 80 is the default port websites use.) You'd need to use a different port. So, say you kept 8888 -- the address would be yoursite.com:8888

WebPack: Accessing Node Environment Variables in client code

I'm working on a project using Webpack to package my client side JavaScript and CSS. It launches a server so I can do hot reloading and other neat tricks. So when I'm debugging my application, the webpack server is running at localhost:3000. I am also using nodemon to launch another web server to host my API calls. It obviously can't run on the same port, so I have to launch it on port 3002.
I have set a node environment variable that tells my api what port it should host on. I need to somehow gain access to that same environment variable in my client script so my ajax calls know what port they need to be calling.
Before I started using webpack, I was hosting my api and my client code from the same port and I could just make api calls like this 'controller/action'. Now that I have them hosted in essentially two different domains, I need to tell my api to call a fully qualified url including the port. ie: 'host:port/controller/action'. I understand that I'll also need to configure CORS on my API server as well.
When I push this to production, I will be hosting both client files and API calls from the same domain once again, so I will be able to continue making relative api calls 'controller/action'. So I need to gain access to the environment variables from my client code so I can determine how to form the api calls in Dev verses in Production environments.

Maybe a webpack devServer proxy would be worth pursuing.
devServer: {
...
proxy: {
'*/controller/*': {
target: 'http://localhost:3002'
}
}
The client would remain blissfully unaware of the differences between development/production.

Dotcloud www and TCP in single app -

I'm trying to get a nodejs socket server running that will allow remote communication between two clients running a Flash game that communicates using a custom protocol. Due to Flash security restrictions, it seems that the socket server must be running on the same host as the web server that servers the Flash game. I've been continuously getting the following error:
The service crashed at startup or is listening to the wrong port. It failed to respond on port "nodejs" (8080) within 30 seconds
What I need is a way to run my nodeJS server code, while simultaneously serve the flash files.
I'm using the environment JSON variables to determine what port to listen on, and my YML is similar to the one discussed here but no luck...
Just wondering if I can get some info on how to create a working socket server/web server that will work for this (or if it is actually possible)

You can use the following dotcloud.yml file:
www:
type: nodejs
ports:
mything: tcp
Then in your Node.js app, you can bind a HTTP server to port 8080, and an arbitrary TCP server to the port contained by environment variable $PORT_MYTHING. Then run dotcloud info on your service; in the ports section, you will see something like this:
- name: mything
url: tcp://myapp-johndoe.dotcloud.com:12345
From now on, if you connect to myapp-johndoe.dotcloud.com on port 12345, you will actually connect to $PORT_MYTHING in your application.
I hope that it makes sense, and that it is what you were looking for!