I'd like to implement push notification server using node.js. The basic scenario is:
Some applications sends notification messages to the server.
Notification server receives the request and forwards the message to uesr's mail or IM client based on user's preference.
In step 1, which protocol (e.g. REST, socket, HTTP/XML and so on.) would you recommend from the performance perspective?
Also in step 2, I have a plan to use node-xmpp module for IM client but for mail, which way is the best to implement? For example,
Just use SMTP. (But I think this might occur performance degradation because SMTP is an expensive communication and performance depends on SMTP server capacity.
use queue mechanism, in order to avoid drawbacks from the above. node.js app simply puts the message into the queue, and smtp server pulls the message.
other solutions...
Thanks in advance.
With regards to what to use as a protocol, i would go for a REST interface, whereby the application posting sends a POST request to a resource associated with the USER. something along the lines of "http://example.com/rest/v1/{userID}/notifications
I personally would use json as the data/content of the rest request and have node.js write this information to a message queue. (as a json string).
You can than have xmpp readers for each user, as well as an SMTP handler reading from this queue as fast as the SMTP server allows it to go.
However, this full post is what i would do in your situation, rather than a factual response on what is best. I know JMS fairly well and i've been working a lot with rest interfaces lately, therefore this is the way i would do it.
Related
I need to interface a secure system that is situated in a protected LAN environment that absolutely must not expose any inbound tcp connections. Thus serving up an http server to provide a means to a webhook service to call as its callback is not an option.
I need to use a third party SMS provider to send and receive text messages. Receiving text messages is the problem.
So I've never really understand how so many services require their customers to provide a webhook. It's such a headache. Companies provide nice things like SDK. For example, when I want to send SMS messages using Twilio of Telnyx for example, I take their jar files, and basically just call a few methods and the SMS is sent without much fanfare. But the fun starts when I want process incoming SMS messages with those (and other) providers. They demand you host a webhook. So there are webhook providers that remove the pain of providing ways to fend of ddos attacks and other heinous scripting kiddies and whatnot, but then those webhook providers still require me to host an http server for it to drop its events to. Why can't I just keep a tcp connection alive to such a provider, and read from a connection that won't send data back until there is something to report, with a periodic heartbeat? And why can't companies like Twilio and Telnyx and others provide all this, without webhooks? It ought to be as simple as providing an event handler interface that simply gets called when needed. The customer shouldn't have to worry about anything more than just dropping in a library and providing a callback method, imo! It's completely feasible, yet it's not provided! Why?
So, because those companies are forcing me to provide a webhook, is there a webhook provider that I can keep a connection open to, where read request trickle out content as needed? A way where I do not have to host any http server?
I am wonder which way would be better to write chat application.
First idea to send message with HTTP request, save in the database, and resend message to recipient using sockets.
Second idea is to do it using only sockets.
I wonder, because I have access and refresh token authentication system with HTTP request, and I think that this way would be safer..
Either way works. Most people use sockets, but you can have a database to save logs and the such. Token authentication is usually done before entering the chat application, but it's up to whatever design you want. If you have no need for logs, just use normal sockets.
Let's say I want to write a mobile chat application (just as an example).
How to receive only the messages meant for one client and don't let other clients receive messages which where not meant for them!?
Create a temp queue only known to the client? - Secure enough?
Encrypting the message with clients public key? - Own PKI needed!
Restrict access to queues based on some credentials the client sends with every request? - Every request needs to be authenticated!
...?
If a client sends a message to the outgoing queue, how to prevent other clients from reading the message directly out of the queue!?
Restricting access to write-only? - Don't know if this is possible...
Encrypting the message? - Own PKI needed!
...?
I hope my question/problem is clear and I'm really looking forward to hear your ideas and best practices!
Thanks in advance!
//edit: So using a temp queue for every client with encrypted messages might be a good choice. Or do you have any other ideas???
If you use RabbitMQ AMQP broker, then you can use Validated User-ID extension power, but you have to create separate users for each client.
Using per-client queue maybe a good choice, but you have to realize that it "security through obscurity" and it smells. But as you suggested, message encryption may fix that.
You can play with Access Control but you may find better to have some server application to handle complex user management things and use it api from clients for better user policies management.
Background: I am building a web app using NodeJS + Express. Most of the communication between client and server is REST (GET and POST) calls. I would typically use AJAX XMLHttpRequest like mentioned in https://developers.google.com/appengine/articles/rpc. And I don't seem to understand how to make my RESTful service being used for Socket.io as well.
My questions are
What scenarios should I use Socket.io over AJAX RPC?
Is there a straight forward way to make them work together. At least for Expressjs style REST.
Do I have real benefits of using socket.io(if websockets are used -- TCP layer) on non real time web applications. Like a tinyurl site (where users post queries and server responds and forgets).
Also I was thinking a tricky but nonsense idea. What if I use RESTful for requests from clients and close connection from server side and do socket.emit().
Thanks in advance.
Your primary problem is that WebSockets are not request/response oriented like HTTP is. You mention REST and HTTP interchangeably, keep in mind that REST is a methodology behind designing and modeling your HTTP routes.
Your questions,
1. Socket.io would be a good scenario when you don't require a request/response format. For instance if you were building a multiplayer game in which whoever could click on more buttons won, you would send the server each click from each user, not needing a response back from the server that it registered each click. As long as the WebSocket connection is open, you can assume the message is making it to the server. Another use case is when you need a server to contact a client sporadically. An analytics page would be a good use case for WebSockets as there is no uniform pattern as to when data needs to be at the client, it could happen at anytime.
The WebSocket connection is an HTTP GET request with a special header requesting the server to upgrade it to a WebSocket connection. Distinguishing different events and message on the WebSocket connection is up to your application logic and likely won't match REST style URIs and methods (otherwise you are replication HTTP request/reply in a sense).
No.
Not sure what you mean on the last bit.
I'll just explain more about when you want to use Socket.IO and leave the in-depth explanation to Tj there.
Generally you will choose Socket.IO when performance and/or latency is a major concern and you have a site that involves users polling for data often. AJAX or long-polling is by far easier to implement, however, it can have serious performance problems in high load situations. By high-load, I mean like Facebook. Imagine millions of people loading their feed, and every minute each user is asking the server for new data. That could require some serious hardware and software to make that work well. With Socket.IO, each user could instead connect and just indefinitely wait for new data from the server as it arrives, resulting in far less overall server traffic.
Also, if you have a real-time application, Socket.IO would allow for a much better user experience while maintaining a reasonable server load. A common example is a chat room. You really don't want to have to constantly poll the server for new messages. It would be much better for the server to broadcast new messages as they are received. Although you can do it with long-polling, it can be pretty expensive in terms of server resources.
Do I need to use a websocket to send JSON data to my client? (it's a tiny session description)
Currently my client-side code sends a session description via XHR to my Node.js server. After receipt, my node server needs to send this down to the other client in the 'room'.
I can achieve this using socket.io, but is it possible to do anything a bit faster/ more secure, like XHR for example?
If you just want to receive the offer from the other side and nothing else, I would suggest you to try HTML5 Server Sent Events.
But this may bring problems due to different browsers support, so I would use a simple long pooling request. Since you only want to get the SDP offer, the implementation is pretty simple.
No, you don't need to use the WebSocket API to send JSON data from client to client via a server, but unless you use Google's proprietary App Engine Channel APIs, then the WebSocket API is probably your best choice.
Also, please keep in mind that you're not only sending session descriptions, but also candidate info (multiple times) as well as other arbitrary data that you might need to start/close sessions, etc.
As far as I know, the WebSocket API is the fastest solution (faster than XHR) for signalling because all the overhead involved with multiple HTTP requests is non-existent after the initial handshake.
If you want to code things yourself, I'd start reading the latest WebSocket draft and learning how to code the WebSocket server-side script yourself or else you will pretty much have to rely on a WebSocket library like Socket.IO or a proprietary solution like Google's App Engine Channel APIs.
How about using the 303 HTTP status code?
The first client send the session description to resource X, the server acknowledges the receipt and responds with a 303 status code that points to a newly created resource Y that accumulates other clients session descriptions.
The first client polls resource X until it changes.
The second client send its session description to resource A, the server acknowledges the receipt and updates resource Y. The first client notices the update with the next poll and will now have the second client's session information.