Everyone that's a bit of a strange question.
I have a product(a Node.js Backend) that's I sell and people deploy it by themselves.
And my goal now is to make them sending data to each other if they want.
they are deployed on private servers.
The data is simple text(writing some text send it to other servers).
it needs to be end-to-end encrypted.
It's not a flow of data in continue(chat Room).
they should have the possibility to send to multiple different servers.
I don't want to use a third-party server to host everything and save the data(they have their own MongoDB Local).
And I don't really know where to start and what to use.
My first problem is do I use regular HTTP requests or WebSocket or any other technology?
Related
I have node.js server, and I need to create dynamically updated web page with updating data. So, I thought that sockets are way to go.
But there's one problem. I need to send data from the server to client(to browser).
From my research, it is not really possible to create socket server with the client side JS. It is easy to do it the other way, but to send data only from server to client?
What would be best and easiest way to do that?
You create a webSocket or socket.io connection from your client to your server and your server is the webSocket or socket.io server. Once that connection is established, you can then freely send data either way across the connection, from client to server or from server to client.
This type of architecture is ideal for sending data from your server to a web page to dynamically update the web page as new data arrives.
webSocket is the base transport. socket.io is a layer on top of webSocket that adds a bunch of useful features such as auto-reconnect and structured messages. You can use either from a browser. webSocket support is built-in to the browser. If you want to use the additional features of socket.io, then you include the socket.io client library in your web page.
Here's a listing of some of the additional features socket.io offers over a plain webSocket: Moving from socket.io to raw websockets?.
I am not sure I have fully understood your question.
But, if I got it correctly, in order to have a "socket connection" you need to have two sides - a server and a client.
Use socket.io lib with a lightweight node.js server.
You can take a look at their docs + examples - will be very straight-forward.
If you still having trouble, write.
I am working on a home automation hub -- a Raspberry Pi running locally that displays weather info, controls my lights, etc. It is "networked" (and I use that term loosely) to a website via a shared MongoDB. Both the site and the hub are running Node.js/Express servers.
Essentially, I am looking to be able to enter text into a field on my website and then display it on my hub.
I'm struggling to figure out how to pass data between them. I can think of a couple ways that might get it done, but the only way I know I could get working is to implement some sort of Mongo watcher/listener to watch for changes on a specific collection. Essentially, you enter the text into the site, that updates the document in Mongo, the watcher informs the locally-running hub, which then fetches and displays the new content.
This seems hacky. Is there a better way? Is this something socket.io could manage? Maybe I'm overthinking it? Help!
You can use Socket.io, WebSocket or TCP socket to connect the two servers together and communicate that way. Or you can use a queue system like ZeroMQ or RabbitMQ and communicate that way. Or you can even make an HTTP request from one server to the other one every time you want it to grab new data - or you could even sent that data right in the request.
It would be much easier if you used Redis that supports pub/sub, see:
https://redis.io/topics/pubsub
or CouchDB that supports the changes feed:
http://docs.couchdb.org/en/2.0.0/api/database/changes.html
or RethinkDB that supports changefeeds:
https://rethinkdb.com/docs/changefeeds/javascript/
I don't think Mongo supports anything like that.
I currently own a website, which will be used for global access and a database. I am also building devices that run a local node.js server, that forms a connection to this website.
So I guess this would be a reverse websocket? I don't own the webserver, it's hosted, so I'd assume I would use php.
I'm needing a 2 way connection that can push or request updates from both ends... Maybe websockets isn't the answer in this case?
I'm new to Web Sockets in general, but get the main concept.
I am trying to build a simple multiplayer game and would like to have a server selection where I can run sockets on multiple IPs and it will connect the client through that, to mitigate connections in order to improve performance, this is hypothetical in the case of there being thousands of players at once, but would like some insight into how this would work and if there are any resources I can use to integrate this before hand, in order to prevent extra work at a later date. Is this at all possible, as I understand it Node.Js runs on a server and uses the Socket.io dependencies to create sockets within that, so I can't think of a possible solution to route it through another server unless I had multiple sites running it separately.
The first question I have is this:
Are you hosting on AWS or in a local datacenter?
The reason I ask is because SOCKET.io requires sticky sessions to work properly across multiple servers. Due to the fact that SOCKET.io will attempt to upgrade each connection, and because that upgrade request must reach the original server that authorized the session, you'll need to route websocket (TCP) connections back to that original server via sticky sessions. Unfortunately AWS makes this extremely tricky and will require you to learn how to:
A) Modify elastic load balancer policies to forward protocol information
B) Split apart TCP connections from standard web requests using something like HA PROXY or NGINX. This is necessary in order to handle web socket UPGRADE requests properly, as you will be setting TCP to sticky and web requests to round-robin.
C) Attach your socket.io configuration to a common storage source, like Redis (elasticache).
Once you've figured out what's needed for AWS (or if you've got full control over request routing at your local datacenter), you'll want to architect your SOCKET application to use multicast rooms rather than direct socket messaging.
Example:
To send a message to users in game #4444, emit a message to room 'games:4444', rather than direct to the user's socket.
If your socket instance is configured using REDIS, REDIS will automatically take care of maintaining lists of people who are connected to your 'games:4444' channel. Otherwise you'll need to maintain the list yourself using a database or other shared mechanism.
Other than that, there are plenty of resources online that can help you figure out each step along the way. I'd start with understanding something like HA PROXY and how it can help split apart your SOCKETS from your web requests.
I would to ask a few questions to better understand some procedures. I'm trying to write a web api project which will be a backend for both web and mobile clients.
The problem that i've in mind is about security. I don't want to use Identity or any other providers. I want to use my own database user and role structures.
Only authenticated client applications should be consuming my application. So that anonymous applications should not consume it.
So what should be the approach ? I 've written a custom AuthorizationAttribute and check some custom headers like "AppID","AppSecurity" key which i store in my own database and if the client sends the right appId and the key it means the app is authenticated to consume the API which does not sound very secure to me.
Another issue is that ; Lets say i've developed a javascript web application and i've to first authenticate the application itself before making GET/POST/PUT/DELETE etc requests which means i've to add some kind of authentication data like username, appkey, password in one of the js files for sending the "AppID" and the "AppSecurity" keys in the header. A client who knows how to use some developer tools or fiddler can easily capture my header values that are being sent to the server side? Even if i pass authentication values on the body of my json request it still can be found on the js files that are sent to the client. I'm also confused about that tooç
So basically i want to build a server side api that will serve the data and get data from the authenticated client applications only. What i need is a simple example for that without using any identity providers.