transfer data from server to remote personal computer

I have a Node.js backend and want to send data through an API to a remote computer which run an app which wrote in python to recieve that data. I use this code in client side:

from flask import Flask, jsonify, request

app = Flask(__name__)  # Create a new Flask app instance

@app.route('/api', methods=['GET'])  # Define a route for the API endpoint
def get_data():
    return jsonify({'message': 'Hello from the API!'})  # Return a JSON response with a message

if __name__ == '__main__':
    app.run(host='192.168.x.x',debug=True)  

and this in server side using Node.js:

const axios = require('axios');

axios.get('http://192.168.x.x:5000/api')
.then(response => {
console.log(response.data);
})
.catch(error => {
console.error(error);
});

when I run these two codes on a same machine it works properly but when I run python code on a machine and Node.js code on another, and I get this error:

cause: Error: connect ECONNREFUSED 192.168.x.x:5000   
  at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1247:16) {
errno: -4078,
code: 'ECONNREFUSED',
syscall: 'connect',
address: '192.168.x.x',
port: 5000

}

Before I came here I use ChatGPT, watch some videos on YouTube but it doesn't help.Also I am beginner in network. If it is stupid to create api in client side what I have to do? trying to switch to socket programming ?

I appreciate any advice or response.

note:
192.168.x.x is my Ethernet adapter Ethernet 3 IPv4 Address.
I expect that recive data from Nodejs code which run on a seperate computer.

> If it is stupid to create api in client side what I have to do? trying to switch to socket programming ?

> I have a nodejs server ,and client will download a python app and run it on its machine. .to transfer data from that server to that application on client side I use API.

any "server" (ie listens to open port, http or otherwise) will need to be on an IP that can be reached by its "clients" (connect to that listening port). if they're on the same local network, their IPs are routable and, firewalls notwithstanding, they can connect to each other. If they're on different local networks, perhaps connected by the internet, then their local IPs are not routable and they cannot connect to each other. So for example, if I'm at my house and you're at your house, we don't share a local network, so we can't connect to each other's local IPs.

In the context of web hosting environments, a server would have a public IP assigned to it. Anything connected to the internet could reach the public IP and make - in your case - http requests.

In the context of home environments. your internet router holds a public IP address and does what's called Network Address Translation, which is a fancy way of saying it rewrites the source IP of outgoing traffic to be its own public IP. The remote recipient of the traffic responds to the public IP of the router, which then rewrites the destination IP back to the original private source, to which it then forwards the request. This is how very nearly all private networks at everybody's house, office, etc will be set up (and the reason IPv4 address space exhaustion never really became a huge problem).

To be able to connect to a machine behind a NAT router, you can't use the private IP in the remote network. It is not routable through the internet (private networks share IP space so they cannot be internet routed). You have to use the NAT router's Public IP space. So you have to log into the NAT router's admin interface and configure it so that incoming connections to a particular port are forward to a particular private IP, which then must be static lest the configuration become outdated.

For clients to run a service that will listen for connections, they will also have to configure their home router to forward those connections and keep that configuration up to date.

This is why it is all but unheard of for "clients" to also open listening ports in current times.

Even if all your clients are power users who can make the necessary configurations, there's really no benefit to it. If you have a webserver, for example, you can GET or DELETE data from the server, or POST/PUT/PATCH data to the server. There's really no reason for the client to also listen on a port.

> client will download a python app

Remember that to run the python app, the client will also need to download and install a python runtime as well as any required dependencies.

Distributing software is actually pretty difficult. Even if everybody already has python installed and you use nothing but the standard library (which does not include your dependencies), you'll also need to update their versions of the code when you find the next bug.

This consideration makes browser centric model of application development very appealing. You don't distribute code (complicated, dangerous) you distribute web URLs. The client simply enters the URL into a trusted browser, and all requisite code (in the form of javascript) and the rest of the web assets are automatically retrieved and executed. Nothing needs to be permanently installed locally. The entire application runs in a well defined sandbox, so the client can rest assured it is much safer.

> Also I am beginner in network.

Everything you're doing is technically possible. You could get all clients to configure their local networks and their systems, download and execute your code. You can write programs that implement all sorts of strange network behaviors. Writing client/server apps is a great way to get to know network programming. But it's a poor way to deliver functionality to clients. Incidentally, web application development doesn't teach you much about network programming anyway - once of its appeals is abstraction around the underlying network layers.

In addition, I strongly advise against distributing client code when at all possible. Even if you end up wanting to make mobile apps, they often work almost the same as websites, so your experience with the web's programming model will serve you well if you end up doing this kind of thing for a living.