Just curious. How exactly does chatting in a browser work? Usually if a user goes to a web page, his/her webbrowser requests the page content. A server produces output and sends it to the user's computer. But with chatting it's a little bit the other way around (well not exactly). It's not the user requesting a chat message from some server, but rather the server that sends it directly. Now this is really simple to achieve with a "normal" server, but the thing that the server sends it to a browser directly confuses me. The posting the message part is all clear, it's simple. You just post the data to the server with for example ajax or something. But how does the other computer instantly "know" that a message has been written to it? It must obviously be the server sending it to the other computer as soon as it has been written. But somehow that doesn't compute in my brain. In my brain, the browser only request things, it doesn't just get them. How exactly do you do that?
Take google talk in gmail for example. How does that work? How is it implemented?
There are some push technologies, such as Comet, but they're not widely implemented. Most of the time this is accomplished via polling at some small interval with AJAX and downloading any new messages that are available since the last downloaded message.
Take a look at Comet
Orbited is a good way to implement this, it uses comet methodologies. You can find a tutorial here.
Someone mentioned ajax polling, but comet is always better than polling. Well, that's just a sensationalist title, but comet is definitely more appropriate and can lead to less stress on the server side, with the right back-end.
It uses AJAX - a client-side javascript running on the GMail user's browser sends and receives the messages from the Google server, and writes them to the browser window - no reload of the page required.
I've develop a browser chat similar to facebook chat technology ( http://chatsign.com ). It is not a push technology but something better than polling, its call ajax long polling.
For more information about ajax long polling you can do some research or visit : http://techoctave.com/c7/posts/60-simple-long-polling-example-with-javascript-and-jquery
Modern chat applications use SSE's (Server Sent Events: a feature of html5) to send new messages to browsers
Related
I want to develop an attendance management page where I want to update my MongoDB database every time when the user leaves the page.
I found unload function in some answers, but cannot realize how to use it in Node.js.
How can I do this using Node.js framework in PhpStorm?
You would have to do it from server side, sending request from client before he leaves the page is a bad approach. There are many ways how client can disconnect without sending any request, like connection lost, killing process etc.
Maybe consider different approach, like sending an ajax request as an indication that user is still on page?
Or you could look around for existing solutions, maybe something like Using node.js to display number of current users
could help.
I'm building a search app using Node.js and Express, and I want to add an autocomplete feature. Previously I've used Socket.io to build a chat app so Socket.io came out in my mind first.
But I did some research and it looks like many people are using AJAX for autocomplete, so what are the difference between the two implementations?
I don't really have much experience with TCP and HTTP protocols so I would really appreciate clear and simple answers for noobs :)
First thing first, your use case is to create an autocomplete feature. What that means? that means when you are inserting a letter in your input field you will request a server with the term you want to find to receive all the autocomplete values.
As a developer when you read this feature details, you should have in mind the word event in our case the keypress event. So each time this event is triggered you want to request the server to get the autocomplete list.
What possibilities do you have to do that ?
First most commonly used for this type of scenarios is a simple ajax call, which will send an request and when finished will update the autocomplete with the corresponding details. As we see in this case for each letter typed, a request potentially can be made (usually you can implement a debounce function) to reduce the numbers of calls. The good think here is that you will close the connection once you received your details, and there are million of plugins with jquery which are doing that just fine.
Second approach is to use socket.io which also is a viable option, you will open your connection once, and for each keypress event you will emit your get details which will be usually faster cause you will reuse the existing connection. The con part here is that you will need to create it by yourself I do not know any plugins which are implementing autocomplete with socket.io.
Conclusion
Socket.io
faster due to reuse of existing connection
more labor work, very little plugins|extensions
good for the case when you already using socket.io on your app
overkill just for the autocomplete feature
Ajax
slower in comparison with socket.io
tons of plugins
overall be a good solution for this use case.
Socket.io/Websockets are primarily for real-time interactions between the server and the client(s). Socket.io also require a constant connection and more setup to have the server respond to a single client. Either way the speed will primarily be dependent on server processing. In the case of a search autocomplete, where you're literally sending a request to the server and expecting a single response back to the requesting client, I'd personally go with the AJAX route. This question has a few good answers that go into detail about this a bit more: What is the disadvantage of using websocket/socket.io where ajax will do?
now I am learning how to build single page web applications with node.js. When I come to the communication part between server and client, I am confusing about the difference between http post request and web socket communication
Here is my understanding:
Web socket like socket.io is asynchronous communication while POST is synchronous communication method.
socket.io is mainly used in dealing with real-time task like html games or dynamic online chatting, or boradcasting some informations.
for validating forms when some user sign up for certain website, it is really good to check instantly if the user name is already been taken or not, I think it is using socket.io to achieve that.
for example in a login page, after I press the username and password, then press 'login' button, I could just use emit things in socket.io to transfer a JSON file with these information. when we checked these information and send back a flag string like 'true' or 'false ' to indicate if the login is success or not.
So my question is:
Why we still use HTTP POST for login and signup ?
Is socket.io better than HTTP POST ?
Why not replace HTTP POST with socket.io ?
P.S for some large files, I have not go into these parts, so I have no idea.
Here is some additions:
After reading a similar question I find I seem to assume that WebSocket is a replacement for HTTP. It is not. It's an extension.
I think this asnwered my third question Why not replace HTTP POST with socket.io.
I have a small Node.js HTTP server that does requests to a mongo database (with the mongoose module).
What I want to do is query the database, store it in a variable (array) and send it to the client.
Because ideally, when the user clicks on one of the buttons on the html page, the JavaScript will pick-up the event and change the appearance of the website by showing calculations based on data that is stored in the database.
The only way I could come with was just "transferring" the database content to the client browser but if anyone can come with another solution that would be fine too !
So basically my question is :
How can I pass a variable from the Node.js server to the client browser when serving a page ?
Thank you in advance !
If you will be doing more than a couple of these types of transfers, I recommend looking into Socket.IO.
It's a layer that provides quick and easy communication between Node.js servers and web front-ends, by abstracting web sockets when available, and falling back to other transports (such as JSON-P or Flash) when it's not available. Basically, you would call io.emit('something', {yourdata: here}), and it is easily received on the other end. All of the serialization is done for you.
http://socket.io/
Give their demo a shot to see how it works.
I already asked a similar question but this one is a bit different/specific:
I'm about to start development of a social community site (for a local user group) with features like timeline, IM/chat, forums, ...
Node.js and socket.io (or now.js) on the backend. jQuery (and maybe backbone.js or similar) on the front end. Content is loaded via socket.io or ajax and navigation via url hash.
There are 2 things where I just can't decide which way to go. I hope here are some people who can provide some good or bad experience.
Templating on server or in browser? I'm not sure if it's better to load a complete html site + live updates (also in html) for timeline, forum posts, IM/chat, ... or use something like a REST api via ajax or socket.io and do the templating on the client site. I've never done that before. You need to download the templates, etc, etc. Has anyone experience in this? There are also 2 ways to implement a rest-like api: E.g. request a forum post, then request the user associated to that post and so on (just like server side MVC) - or - request a forum post and the server answers with all needed information.
Load content via ajax or socket.io? I'm definitively using socket.io or now.js for real-time communication (IM, chat) and pubsub (on mainpage -> subscribe to new timeline updates, on a forum topic -> subscribe to new posts). But should I also load HTML (or provide a REST-like API, see question 1) through the socket? When people open forum posts in tabs (which I usually do a lot) that would mean a lot of socket connections. And I'm not sure how long it takes for a websocket to establish connection.
So there a 4 ways to do this:
HTML via AJAX - probably the most stable way that doesn't need a lot javascript to do the templating - Browser can use open HTTP connections to request stuff.
HTML via socket.io - The websocket must be established to load content (may be slower)
API via AJAX - as it probably needs more requests as HTML via AJAX there might be some HTTP header overhead + you need to authentication in each request- I'm not a friend of too many ajax requests.
API via socket.io - Socket must only be authenticated only once and you can request API objects on the fly. However I would still load templates and js via HTTP for browser caching.
I know this is a huge post but I'm debating for many days now and just can't decide as it would be a lot of work to switch the system once started developing. This is not a public project, it's limited to ~10k-15k local people and thus must not be that perfect, a good opportunity to learn new things in my opinion (I'm completely new to node, classic PHP MVC + jquery dev here).
I think you should use a RESTful api on the backend, let the templating occur just on the frontend (maybe with Backbone) and only use Socket.IO for real realtime stuff (such as chat). It doesn't make any sense to use websockets for something like loading HTML, because it most likely never changes.
So my vote is:
1) HTML via AJAX
2) API via AJAX
3) Realtime communication, such as chat messaging (or other stuff that constantly changes) via Socket.IO
Though there really isn't a definitive answer, as it depends.
If you need to be search engine crawlable, you can NOT rely only on client-side processing. If your individual views are light, and/or you need to support mobile, you should have initial rendering server-side.
Currently, I would suggest using an API that both your client application and server-side can use. If you use node for the server-side rendering you can re-use a lot of the same logic, including the API client.
Going a few steps farther, if you look starting with the Yahoo flux examples project on github, you can use the same logic both client and server-side including rendering with React views. This is not an easy solution, and will take some work.
For interactive elements, server-side rendering can be minimal with your stores pushing an event wiring up via sockjs/socket.io when the client starts for your chat/im bits.
You will have scalability issues when it comes to running across multiple processes and will likely need a pub/sub chain backed by a db for longer re-connect cycles or missed IM messages. There isn't a magic bullet.
Right now, I like flux+react... When Angular2 comes out, it may have a better story for server-side rendering.