I pretty much don't know anything about these two. Which one is better/more efficient and why?
Also I looked at the node.js example and noticed that they create a server for the chatroom/chat.
Does that mean I need to create a new server for every chat/chatroom or is there a better/more efficient way of doing this?
Thanks!
Socket.io is a library which utilizes node.js. Think of node.js as an javascript on the server. Socket.io provides modules for websocket servers (server-side) and websocket clients (client-side).
I do not entirely understand your question about creating a new server for every chat/chatroom. That's entirely up to you.
Related
I've tried implementing a peer to server connection with WebRTC, unfortunately node-webrtc doesn't provide typescript types, which makes it really hard to add collaborators, and messes up the codebase.
Is there any other way to make a client to server connection using NodeJS and WebRTC?
Yes! Check out werift-webrtc it is a typescript implementation of WebRTC for node.js
Ok, so instead of using typescript, I've started building my own webrtc broadcadting media server using the native code I found here: https://webrtc.googlesource.com/src/
I also took inspiration from the way Discord created their servers, I found this information on this blog post: https://blog.discord.com/how-discord-handles-two-and-half-million-concurrent-voice-users-using-webrtc-ce01c3187429
I still havent't figured out a way how am I supposed to do this, what I think we have to do is to create a RTC Peer Connection using the api/ directory in the native code, or something like that.
The answer above me, that I've marked as accepted, is useful if you want to go through the nodejs typescript way, I'll try figuring something out and keep you guys updated.
Hello !
A bit of background, I'd want to create my first android/iOS/webapp. The idea is to create a cross platform chat using :
Ionic (and Javascript) for the app
Openshift for the node.js server part
I was going to use Firebase to store the messages, but the free plan just works for 100~ simultaneous users, which ain't a lot ... So I was thinking about creating a node.js server using MongoDB to store everything. Users and messages.
The idea is that I'd get a better server side control on the data, and it seems to be nicer to me.
But is it actually a good idea ?
I'm not sure about the fact that it's pertinent to use a node.js server for that matter, I'm pretty new to those technologies (I'm a Java/COBOL developer)
Thanks in advance !
tl;dr : is storing and processing data for an iOS/Android/Webapp chat with a node.js server is a good idea ?
I think it's a good idea, in few hours you would have a working environment. With Ionic, being web technologies, you can use any library you want, probably the easiest one to use could be socket.io, is simple to use client side and simple server side. You would have rooms and everything already to exchange messages in realtime.
There are a ton of examples for using socket.io to make a chat so should be pretty easy to find infos. ( I made one myself )
I want to make small chat app in nodejs.
But every where i found that to achieve this functionality node is used with socket.io
As node was also created with push notification in mind so thinking
How to create chat app purely in node if possible ?
Thanks!
I want to make small chat app in nodejs. But every where i found that
to achieve this functionality node is used with socket.io. As node
was also created with push notification in mind so thinking How to
create chat app purely in node if possible ?
Yes, it is possible to create a node.js application that supports chat without using socket.io. You have these choices:
Use a straight webSocket to "push" to the client. You will need to find or write your own server-side code for handling the webSocket protocol because such code is not built into node by default. The ws module is one such library. If using a plain webSocket, you will likely have to implement on your own some of the functionality that socket.io implements such as auto-reconnect.
Find some other library (besides socket.io) that is built on top of a webSocket that would let you push data to a client.
Invent your own substitute for a webSocket (probably client polling or long polling) and code that. This is what was done before webSockets existed. It is much less efficient than a continuously connected webSocket.
All of these choices involve writing some code that has already been written for you in socket.io so most developers would rather just use the already working and already tested solution rather than reimplement it themselves.
To get into further detail in your question, you will need to define what "purely in node" means to really answer this question. That's not a well defined term. The socket.io library is just a library written in Javascript just like thousands of other libraries you can use in node.js to get your job done.
As you quickly see with node programming, you can't do very much at all in a default node instance without loading other libaries. Some of these libraries come with a default installation of node (like the fs library or http library, for example) and others are libraries that you install before using (usually as simple as typing "npm install socket.io") and then var io = require("socket.io");.
If you are not going to use the socket.io library, then you need a mechanism for "pushing" data to a client in order to make a chat application work. The only true "push" that has any cross-browser support is a webSocket. A webSocket is what socket.io uses. You could use a webSocket from node without using socket.io, but you'd have to write or find code that implements the webSocket protocol that you can run on node (the ws module is one such library). Such code is not built into node by default.
If you weren't going to use webSocket, then there is no other cross-browser method to "push" data to a browser client. Your only other alternative I'm aware of would be browser polling which isn't actual push, but tries to simulate push by just regularly asking the server if the server has anything new for a particular client. An enhancement to straight polling is "long polling" which was invented before we had actual push with webSockets.
All of this problem has already been solved in socket.io so unless you really just want your own research project to rebuilt similar functionality in your own code, you may as well build on solutions that have already been done by using something like the socket.io library.
If you have some specific objection to the socket.io library, then please explain that objection so we can understand what your real goal is here.
Node.js doesn't come with an out-of-the-box server-side Websocket implementation, so you will have to, at least, introduce a package which does.
If you don't want to go with socket.io, you can then defer to ws, which is what socket.io uses under the hood.
I'm using node.js+socket.io in my projects, and one of the issues that bothers me the most is absence of normal AS3 library than can handle communications between as3 and node.js using socket.io.
In my last project, I used https://github.com/simb/FlashSocket.IO this library, but I had to roll back to node.js v0.8.25.
So - requirements:
Works with node.js v0.10.x
Works with socket.io v0.9.x
Secure connection support (wss)
It would be nice to have more than one library, maybe someone knows a better one?
Thanks!
I also needed this, so here's what I used: https://github.com/sinnus/socket.io-flash.
requires Socket.IO(>= v.0.8)
I've build several websites using PHP and mySQL as backend, and believe that I'm fairly familiar with both. However during research for my new website I've come across node.js and mongodb (and socket.io, since the site is gonna contain a chat).
I've decided to use node.js and mongodb to run the chat - but don't know if I should just do the entire site with those two things?
Since I'm gonna run a node server anyway should I just run another (seperate) one hosting the website? Or is that an bad idea? - is it stable?
I could do the programming in PHP and still be using mongodb - but wouldn't node be way faster?
And another question:
I've planned to use ajax to handle all the posts to the page - but since I'm allready using socket.io to the chat - should I do all my post request using that?
For the ajax I've planned to use jQuery (also for all frontend effects).
don't know if I should just do the
entire site with those two things?
If you want to learn node.js then there is nothing better than coding it.
Since I'm gonna run a node server
anyway should I just run another
(seperate) one hosting the website?
You can use existing server and run your node.js app on other free port(o). I think for learning node you don't need to have dedicated machine.
is it stable?
Even versions of node.js are stable releases, however until there is 1.0 with feature freeze there could be breaking changes to its API.
I could do the programming in PHP and
still be using mongodb - but wouldn't
node be way faster?
It most probably (and definitely) would.
I've planned to use ajax to handle all
the posts to the page - but since I'm
allready using socket.io to the chat -
should I do all my post request using
that?
I would recommend stick to MVC model and use express since you can get into lot of time consuming troubles if you would use socket.io for classic stuff. Socket.io is namely for real-time functionality and things related to that.
There are already some solid web frameworks for node.js, in particular check out Express. Here's a really good article outlining some lessons and experiences from building a node.js website:
What it’s like building a real website in Node.js
Regarding your second question, it's probably still best to use AJAX handlers and HTTP with jQuery. I'm not sure that jQuery supports callbacks over raw TCP sockets.
node.js + express + jade + stylus + jQuery is my preferred environment.
Using forever to auto restart the server I've never had any real up-time issues even when I have bugs crashing the server on a regular basis.
As for socket.io + jQuery, they do get along fine, but it's just not as natural as the express + jQuery combo. I'd stick to making ajax calls for most things.
Node.JS can still be a little wild west like, but its improving. It is a very different model from coding in php, but it is very well suited for a lot of websites. You'll probably want to do the thin server (expose a REST API and your websocket endpoints) with a fatter client using something like BackBone.js to keep interactions clean.
The big win from doing the whole thing in node is that you will not have duplication of code between php and js for dealing with the DB or any other services required by both. Node.JS is also fantastic at handling tons and tons of concurrent requests.
Good Luck