I'm building a simple node app for broadcast messaging using socket.io. It will have 3 users at a time
user 1: Moderator (gets a stream of social media comments from various APIs, picks messages to send to user 2 and user 3)
user 2: Graphics (displays messages pushed from user 1 as graphics in OpenBroadcastSoftware)
user 3: Host (displays messages pushed from user one on an iPad (to field viewer questions)
This is all for realtime use, nothing needs to get saved or logged.
I know all the basics of sending and receiving socket.io messages.
My question is, for portability, I want to host this App on Heroku
If this was a single Free/Hobby dyno app, would I need any sort of backend like Redis? Or would it work as if i was hosting the app on a local server since there is only once instance?
This app is never going to have more than the 3 users described above, so I'm not looking to implement any scaling what-so-ever
Thanks!
No You don't. The websocket can work with just the app, tested it out.
Related
I'm trying to build a realtime (private) chat between users of a video game with 25K+ concurrent connections. We currently run 32 nodes where users can connect through a load balancer. The problem I'm trying to solve is how to route messages to each user?
Currently, we are using socket.io & socket.io-redis, where each websocket joins a room with its user ID, and we emit each message they should receive to that room. The problem with this design is that we are reaching the limits of Redis Pubsub, and Socket.io which doesn't scale well (socket.io emit messages to all nodes which check if the user is connected, this is not viable).
Our current stack is composed of Postgres, Redis & RabbitMQ. I have been thinking about this problem a lot and have come up with 3 different solutions :
Route all messages with RabbitMQ. When a user connects, we create an exchange with type fanout with the user ID and a queue per websocket connection (we have to handle multiple connections per user). When we want to emit to that user, we simply publish to that exchange. The problem with that approach is that we have to create a lot of queues, and I heard that this may not be very efficient.
Create a queue for each node in RabbitMQ. When a user connects, we save the node & socket ID in a Redis Set, so that when we have to send a message to that specific user, we first get the list of nodes, emit to each node queue, which then handle routing to specific client in the app. The problems with that approach is that in the case of a node failure, we may store that a user is connected when this is not the case. To fix that, we would need to expire the users's Redis entry but this is not a perfect fix. Also, if we later want to implement group chat, it would mean we have to send duplicates messages in Rabbit, this is not ideal.
Go all in with Firebase Cloud Messaging. We have a mobile app, and we plan to use it for push notifications when the user isn't connected, but would it be a good fit even if the user is connected?
What do you think is the best fit for our use case? Do you have any other idea?
I found a better solution : create a binding for each user but using only one queue on each node, then we route each messages to each user.
I spend already 3 days for reading, watching tutorials about WebSockets, socket.io, node.js and so on.
Basically, I'm a Laravel developer and have just a basic idea about all the rest components.
With regret, after these 3 days I don't have in mind all logic step-by-step of implementing this architecture. I will try to explain what did I understand and you please correct me.
So :
WebSockets - is a bidirectional continuous connection between client and server. It uses another port, and basically it is not a HTTP/S connection.
For making this kind of app like I said, we need one more server, and idk why, but this is Node.js. At this Node.js server we should install socket.io (server-side package) and Redis.
Then, we need to add client-side socket.io (via CDN probably).
At Node.js server we are creating a server.js file where require all modules that we need, like socket.io and Redis. We open a connection for a specific non-used port (as 6001). Then we run this node server.
At front-end we are subscribe-ing to this channel and define method for emitting and listening to the server.
Example :
User1 is connecting to a specific route. User2 as well. User1 type a message for User2, when press Submit, message from User1 is sent to Node.js server, where it is sent in Redis(yes? if yes - Why?), and then Node.js is listening for what to do in this case, and send this message to specific user, or with broadcast to all users except the publisher.
Oh, it's even hard to explain that, too much steps and tehcnologies used.
Can please someone correct my logic? I really want to understand all that process and logic of using this components. Or please, give me some useful articles and videos, may be I didn't saw them. Thanks!
I suggest you read the official docs on how to build chat. Basically what you will have in the end is 2 servers, 1 for your Laravel app and the other for chat (Socket.io) . The key to this is using broadcasters and listening for events on both sides, frontend and backend.
Events are broadcast over "channels", which may be specified as public or private. Any visitor to your application may subscribe to a public channel without any authentication or authorization; however, in order to subscribe to a private channel, a user must be authenticated and authorized to listen on that channel.
I am using Angular CLI latest version and NodeJS, want to archive web push notification, we got few documentations but gives error, May I know any Documentation for web push notification which supports angular and nodejs.
The requirements are send push notification to all users who notification granted while browser closed as well.
Sample docs :
https://ciphertrick.com/2017/03/14/browser-push-notifications-in-angular-applications/ (getting error pushNotificationModule not exported)
https://www.npmjs.com/package/angular2-notifications (Not clear for CLI)
The Angular2+ directive angular2-notifications is doing only the last part showing the message in UI/UX. And that is the least of your challenges.
You say:
The requirements are send push notification to all users who
notification granted while browser closed as well
The part 'while browser closed as well' is the tricky part.
This means you need a Service Worker. A Service Worker is a script that your browser runs in the background, to which the message is being pushed when the browser is closed. For a nice introduction to Service Workers, read this. Angular has a Service Workers implemented in production version since 5.0.0. Klik here to read more about it.
I don't think setting up a WebSocket connection (like socket.io) from Node to a Service Worker is possible. It's complicated, some people say it's possible, others say no. See this for more info. I would at least say that it is not stable enough, so you need a 'real' push notification.
You can use a push notification provider to do the job. Click here for a list of them. You pay for these services.
If you want to do it yourself (free of costs) you can use Google's cross-platform messaging solution Firebase Cloud Messaging (FCM) (the successor of Google Cloud Messaging (GCM)).
To connect your NodeJS server with the FCM you can use different libraries e.g. node-pushserver and many others.
Im using nodejs and socket.io to deliver a chat on my business app, but i want to distribute the deploy so i can have as many chat servers i want to balance the load of the traffic.
I try the load balance approach from nginx but that just do that balance the traffic but the communication between the socket.io serves its not the same, so one chat message send from user A to server S1 wont travel to user B on server S2.
There is any tool or approach to do this.
Thanks in advance.
===== EDIT =====
Here is the architecture of the app.
The main app frontend on PHP CodeIgniter lets tag it as PHPCI
The chat app backend on NodeJs and SocketIO lets tag it as CHAT
The chat model data on Redist lets tag it as REDIST
So what i have now its PHPCI -> CHAT -> REDIST. That work just fine.
What i need is to distribute the application so i can have as many PHPCI or CHAT or REDIST i want, example
PHPCI1 CHAT1
PHPCI2 -> -> REDIST1
PHPCI3 CHAT2
Where the numbers represent instances not different apps.
So a User A connected to PHPCI1 can send a message to a user B connected on PHPCI3.
I think some queue in the middle of CHAT can handle this something like rabbitmq that can only use the SocketIO to deliver the messages to the client.
If you're distributing the server load (and that's a requirement), I'd suggest adding a designated chat data server (usually an in-memory database or message queue) to handle chat state and message passing across edge servers.
Redis Pub/Sub is ideal for this purpose, and can scale up to crazy levels on even a low-end machine. The Redis Cookbook has a chapter on precisely this use case.
If you set up the server-side of your chat app correctly, you shouldn't have to distribute socket.io. Since node.js is browser-based and doesn't require any client-side code (other than the resources downloaded from the webpage), it works automatically. With a webpage, the files required to run socket.io are temporarily downloaded to users when they are correctly included (just like with jQuery). If you are using node.js and socket.io to make an android app, the files should be included in your application when you distribute it, not separately.
In addition, if you wish to use two separate socket.io servers, you should be able to establish communication between the two by connecting them in a similar manner that a client connects to the server, but with a special parameter that lets the other server know that a server connected and it can respond and set a variable for the other server.
I am new to server-side development. I'm trying to learn by doing so I'm building an application with express on the server, mongodb as my database and angularjs with twitter bootstrap on the client-side.
I dont know if this is the most practical way but when thinking about how to implement messaging between users I thought of a mongodb model called Conversation with an id and an array of the ids of every user in the conversation and another array of strings that correspond to messages. And then add this model to my REST API.
But lets say all/some of the users in the conversation are online, why not benefit from socket.io. So how can i switch from this to real time chat? Does the interaction with mongodb occure exactly as explained and socket.io just notifies every online user that an interaction has occured? If yes, how? Or is it something else?
socket.io can send real time events to connected sockets, you can use a database for storing messages that are failed to deliver and for offline users.
also, you might want to use something like Redis for this as it has channels with subscribe and publish capabilities.