Is there anyway to send data though sockets from Node.JS to SignalR? I have a Node.JS app that sends realtime information as JSON format. The other app it's an MVC C# app that uses SignalR to send the data to the client via socket. I want tosen data from de nodejs to signalr and signal send that info to the client.
You might consider better solution for internal communication between processes. SignalR is meant to be used between .Net server and client using different authentication, handshake, protocol and network layer methods, which is inefficient for internal server communication.
Take a look on ZeroMQ, is well simple and very easy to use tool, meant especially for such cases. It has bindings for most languages including .Net and node.js.
There is js client for browser to communicate with Signal R server.
http://www.nuget.org/packages/SignalR.Js
You probably can extract js file from it and run from Node.js.
And probably standard Socket.IO will just work, you need to subscribe to proper events and go.
If you want a node.js client for signalR that doesn't require jQuery I started this one. It intentionally only supports websockets.
https://npmjs.org/package/signalr-client
Related
I'm developing a react app and I need to trigger notifications in it for database changes , My back end is node and I'm not sure how to achieve this task. Should I listen always from front end for back-end notifications?I need to do It like how they do it in Facebook, When I develop my flutter apps I used Firebase streams to achieve this and don't know how to do this in react and node with PostgreSQL database.
You can use web sockets or socket.io library.
https://socket.io/
Old browsers don't support web sockets, in that case you need to check repeatedly from the front-end whether there is any notification from the back-end, lets say when database changes. This is called polling.
But, socket.io supports this polling automatically if browser don't support web sockets.
Socket.io is used by many applications . Your purpose seems to be solved using this library. It is event based. Once there is any database change in backend, and if you set up a socket.io event emitter, your front end will receive it via socket.io on the client and your react app can finally notify the user.
From their website,
Socket.IO enables real-time, bidirectional and event-based communication.
It works on every platform, browser or device, focusing equally on reliability and speed.
I'm new to working with sockets and have a small system design question:
I have 2 separate node processes for a web app, 1 is a simulator that is constantly running and the 2nd is an api server. Both share the same MongoDB database and we have a React app running for the client, served by the api server.
I'm looking to implement socket.io for real-time notifications and so I've set up a simple connection between the api and client.
My problem is that while the simulator runs, there are some events that I also want to trigger push notifications for so my question is how to hook that into everything?
The file hierarchy is like:
app/
simulator/
api/
client/
I saw this article for communication between node processes and I currently have 3 solutions in mind:
Leave hierarchy as it is and install socket.io package inside simulator as well. I'm not sure if sockets work this way but can both simulator and api connect to the same socket?
Move simulator file into api file to fork as a child process so that the 2 processes can communicate via child/parent messaging. simulator will message api which will then emit updates through the socket to client
Leave hierarchy as is and communicate via node-ipc. Same situation as above with simulator messaging api first before api emits that to client
If 1 is possible, that seems like the best solution in my impression. It seems like extra work to add an additional layer of messaging for 2 and 3.
Leave hierarchy as it is and install socket.io package inside simulator as well. I'm not sure if sockets work this way but can both simulator and api connect to the same socket?
The client would have to create a separate socket.io connection to the simulator process. Then, the client can receive data from the API server over one connection and from the simulator over another connection. You would need two separate, independent socket.io connections from the client, one to the API server and one to the simulator. Simulator and API server cannot share the same socket unless they are in the same process.
Move simulator file into api file to fork as a child process so that the 2 processes can communicate via child/parent messaging. simulator will message api which will then emit updates through the socket to client
This is really part of a broader option that the simulator communicates with the API server and sends it data that the API server can then send to the client over the single socket.io connection that the client made to the API server.
There are lots of different ways for the simulator process to communicate with the API server.
Since it's already an API server, you can just make an API for this (probably non-public). The simulator calls an API to send data to the client. The API server receives that data and sends it to the client.
As you suggest, if the simulator is run from the API server as a child process, then you can use parent/child communication messaging built into node.js. Note, you don't have to move the simulator files into the API file at all. You can just use child_process to launch the simulator as another nodejs app from another project. You just have to know the path to that other project.
You can use any another communication mechanism you want between the simulator process and the API server process. There could be a socket.io connection between them. You could use several forms of IPC, etc...
If 1 is possible, that seems like the best solution in my impression.
Your #1 option is not possible as separate processes can't use the same socket.io connection.
It seems like extra work to add an additional layer of messaging for 2 and 3.
My options #1 and #2 are not much code in each server. You're doing interprocess communication. You should expect to use some code to enable that. But, it's not hard at all.
If the lifetime of the simulator server and the API server are always together (they have no independent uses), then I'd probably do the child process thing where the API server launches the simulator and then use parent/child messaging to communicate between them. You do NOT have to combine sources to do this.
The child_process module can run the simulator process by just knowing what directory it is located in.
Otherwise, I'd probably make a small web server on a non-public port in the API server and have the simulator just send data to that other web server. I often refer to this as a control port. It's a way of "controlling or diagnosing" the API server internals and can only be accessed from within the private network and/or with credentials. The reason I'd use a separate web server (in the same nodejs app as the API server) is to make it easy to secure so it can't be accessed from the outside world like the regular public APIs can. You just put the internal web server on a port that is not exposed to the outside world.
You should check Socket.IO docs about adapters and Emitters. This allows to connect to sockets from different node processes and scalability.
I am in the process of developing a chat application using Javascript. When sending messages from one client to another client, do I have to send it through a server or can I send it directly from a peer-to-peer approach, using something like websockets ?
Welcome to the stage of life where you see the importance of design patterns.
You can start solutionizing with mediator pattern and proxy pattern with web sockets.
Wheater you need a server or not is up to your design.
Technology-wise there are multiple APIs that HTML5 offers you can go through them and make something on your own.
There is a bunch of APIs available with HTML5 and JS.
Start digging on WebSockets, Server-Sent Events, Web Workers.
The server will give you the flexibility of record-keeping while acting as a mediator. Alternatively, you can come up with a pure p2p design with a scheme where every node or user notify other users with their details(IP) for establishing communication. Remember for web socket to work the client need to know what address to connect to. Maybe it can have fixed master nodes. Then you can use observables for polling and other features. Take a look at the BitTorrent protocol for design inspiration.
Get creative and start designing.
There are many ways to do it. I recommend the scheme:
Peer <---> custom websocket server <---> Peer;
I recommend NodeJS with SocketIO.
When I read about how to create chat applications in Node.js, I found out that the recommended way to do so was to use Socket.io and websockets.
I also read that we can regularly send requests using AJAX and wait for responses from the server.
So my question is: Can AJAX serve the same purpose as WebSockets, and use AJAX for chat applications instead of WebSockets?
You don't have to use websockets for chat applications, there is actually a wide range of technologies you can use.
AJAX: AJAX, or long polling can be used for web chats, but is considered a primitive and inefficient way to get updated chat information. The client listens for a change on the server-side, then when it get's a response from the server, it then makes another request to listen for requests. The reason this is looked down upon is because they client could be listening for a long time, without a response from the server.
WebSockets: Websockets is a protocol that runs over HTTP that facilitates bi-directional data. Similar to the TCP websocket protocol, there is a 3-way handshake involved in order to make a connection. Socket.io aids in the use of websockets by abstracting a lot of the raw websocket functions. The truth is that Socket.io actually provides backwards compatibility with browsers that only support long-polling or Flash for chat communication. Unlike WebRTC, there is a man-in-the-middle (server) to facilitate who is chatting with who.
WebRTC: WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. These protocols allow peer-to-peer communications (chat included) with little use of a middle-man, or server. To address your question, it's great for "private-chats".
Flash: It is possible to use Flash for chat communications over the web. This is severely outdated, as Flash is slowly dying from the web.
I'm new to node.js, so i have some questions about connect framework and socket.io:
What's different? i'm confused about it.
Should i use connect fw with socket.io or just use socket.io?
The Connect module is a web application framework, while Socket.IO is a realtime transport module. You would use one to create web applications, and the other for bidirectional communication between a server and a client.
Here's a few of the things the modules can do:
Connect:
service static files and pages
provide cookie-based sessions
accept file uploads
handle HTTP verbs (GET/POST/PUT/DELETE)
Socket.IO:
authorize connecting sockets
send data between server and client with multiple transports
supports (WebSocket/XHR long-polling/flashsocket/JSONP)
So if you wanted to create a website, you would use Connect. However, if you wanted that website to have something such as realtime chat capability, then you would use Socket.IO.
Whether you should use one module or the other, or use them together, is dependent on your application requirements.
Connect is special module which can provide scalable functionality. You can just add features as middleware. It reminds some kind of configuration of your project, it just simplify routine.
var app = connect()
.use(connect.logger('dev'))
.use(connect.static('public'))
.use(connect.bodyParser())
.listen(3000);
After adding this for example you can access features which connect provide. For example you can have logging (method url and seconds) for each application activity, or add session support, easy with one line of code. The same way you can add socket support I suppose.