I have an angular application deployed, but when it creates requests it makes all petitions from client to server api's, that is not desirable because it forces me to publish to internet the api server ports
Is it possible to make all petitions internal ?
Related
I am trying to build an app to retrieve data from a local database, The structure of the app that I have a mobile app, server(on a hosting service), and local server(on my pc), I am trying to make the mobile app request data from the server via a normal HTTP request then the server request the data from the local server but the problem that I could not be able to connect with my local server I believe that I could not connect to my local server because my local server does not have a public IP, so I am trying to find a better way to achieve my idea.
I read something about Websocket but I don't know if it suitable for my idea beacuse it is Bi-directional connection and It most used for chatting app
I want to build the app with NodeJs, so what should I do to implement this idea, and thank you for the help.
Each server is on a different network the main server is on Heroku host and the local server is on my personal computer
Life would be a lot easier for you if you move your local server to Heroku where they can much more easily and securely talk to one another.
You can't connect from your Heroku server to the server on your private local network because it is behind a firewall in your home router. To allow such a connection, you have to configure a known public IP address for your home network (that won't change or use DDNS if it can change) and configure port forwarding in your firewall/router so incoming connections from the internet on a specific port can reach your local server. You will then have to harden your local server against random internet attacks since it will then be open to the internet.
One other possibility is that you could have your local server connect to your Heroku server (perhaps with a webSocket connection using some sort of secret credential). Since your Heroku server is already reachable from your home network, this would require less networking configuration change. Depending upon what you're trying to do between the two servers, you could either have the local server just make a regular http request to the Heroku server (either sending data or asking for data) or you could make a webSocket connection and then data can be sent either way of the webSocket connection.
I have a C# server side web service. but I don't want user can to see my requests like request tab from client's browsers.
now, I haven't been find any solution on SO.
what is the best solution to do this?
I think I can use a node.js server-side and render my reactjs inside it and my node.js send my requests to C# server side. like this:
React.js<--(render)--Node.js--(Send/Receive api's)-->C#
I don't know if I use a node.js server, my requests will be hidden from clients?
I don't want to use reactjs.net.
If you're making a HTTP request to node server, and making the stealth request from NodeJS to another server, that request will not be visible to the client.
Alternatively, you can make an encrypted request. Although URL and some part of encryption algorithm will still be exposed at client's end.
I'm a beginner learning node and angular but running into many issues. I have Angular running on Node, and my code in Angular makes http requests to retrieve json from an API on another web server (this web server is something I add routes to and I'm not allowed to enable CORS on it). I'm getting 'CORS blocked' due to my http request although I know this resource is accessible. I understand that you have to enable CORS in the web server but in this case that is not an option. There is another web app (not running on the same origin as the resource) that is doing a similar thing to mine but instead he uses node to retrieve the json data and then I think he sends that to angular to process. Is this a possible work around?
Yes it is. If you can't enable cors headers on the server then the only thing you can do is access the server from your nodejs or any other type of server. If you eventually plan to run your angular in cordova you could make a direct $http request because cordova does not block corsable requests.
I'm trying to make a web socket connection on my webserver. The connection is run from a client in javascript and connects to a php script on the webserver. The javascript is also placed on the webserver, but runned from a clients webbrowser.
The problem is that hostgator doesn't allow inbound socket connections unless you buy a dedicated server, but I'm not aware if this counts as an inbound socket connection.
So does anyone know if this counts as an inbound socket connection or any other web hosting sites that would allow inbound connections?
Thank you in advance :)
A websocket connection starts life as an incoming HTTP connection (usually on the same port as is being used for web requests) with some custom headers on it which is something all web servers have to be configured to accept (or they wouldn't be any use as a web server). After a brief exchange with the client, the client requests an upgrade and a switch to the websocket protocol (the initial connection was the HTTP protocol). That connection which started life as an HTTP connection then becomes a webSocket connection (if the web server agrees to the protocol switch).
So, yes it is an incoming connection to the web server, but it's an incoming HTTP connection which your web server has to already accept. webSockets were designed this way on purpose to make them highly compatible with existing HTTP networking infrastructure, firewalls, etc... so they could be used by only upgrading the HTTP server software (to support the webSocket protocol) and not changing any of the networking infrastructure.
FYI, there are other hosting issues with using webSockets. A webSocket is a continuous, long lasting socket connection. In order to use it, you typically need a continuous, long lasting server process. Many of the lower cost, shared hosting environments do not support that. They tend to accept an incoming HTTP request, dispatch it to whatever script it is supposed to run (e.g. a PHP script), let it run on that request and then the script exits and your server process does not continue to run. This works well for low cost, shared hosting because no server resources are consumed by your app when it is not actively in the middle of serving a page. But, that model won't work for webSockets where you must have a continuous server process for the webSocket to be connected to.
I don't know specifically about hostgator, but this is another issue to look into. On my shared hosting on Dreamhost, I cannot have a long running server process. On Dreamhost this requires a VPS hosting plan and from what I've read this is common for other shared hosting environments too.
I'm making connections via thrift (node-thrift) to a backend server to make api calls, but the communication is bidirectional (push/pull) to NodeJS.
While a user is browsing around different URLs, and Node is churning out jade templates and javascript files via Connect/Express routes, how do I maintain the connection to the backend server, and output (as an example) the connection status as part of the rendered jade output?
I have the connection object, but what do I do with it?
Sockets and port communication is generally a new area for me, so any help would be appreciated.
Keep in mind that backend server is not communicating to the web browser as the client, but rather the NodeJS server as the client.
(updated after discussion in comments)
So it looks like thrift is TCP-based which means the node client is going to keep the connection to your thrift API server open. This is entirely independent of what your node/express app server is doing with the browser clients. So if you keep a reference to your thrift client available to all requests, by attaching it to the app object for example, you should be able to determine it's current status and include that information in HTTP responses to the browser. There's not going to be any automatic coordination or association of any kind between your express app server handling browser HTTP requests and your thrift client making RPC calls to the API server. If you want coordination, you need to code that explicitly, but sending an HTTP response to a browser isn't going to automatically close your thrift TCP connection to the thrift RPC server (and same story vice versa).