The tutorial for spring websockets brings in a whole army of technologies, and has you build a really complex chat application, but for someone who just wants the most simple possible example of web socket tech, it's way too much, without enough explanation of all the moving parts.
I have it running, and its pretty and all that, but I still don't know what STOMP is vs MQTT vs sockjs.
What I would like, is the most simple, websocket example.
Some server block that spews a string, and a very few number of lines of javascript that prints that to the console.
Then I can start to understand all this.
Can anyone point out a "hello world" spring websocket example that is much much simpler?
Related
I am trying to figure out whether I can build a web application completely on Ruby stack.
I am looking for following architecture:
Frontend <--- Websockets with Pub/Sub ---> Backend
On top of that, I really like Rails approach with "convention over configuration". As result, I am looking for some "opinionated" framework which will handle this scenario.
I know that it's easier to achieve with Javascript stack. As example using Sails.js.
However, it's experiment. So, I am not looking for the most efficient solution.
Has anybody build anything like that? What would be a reasonable set of libraries/frameworks to build something like it?
Since you said it's an experiment, I would recommend you to try out Volt. It uses Opal, which transcribes Ruby to JS and has reactive synchronization which Meteor.js is famous for. Also there are a lot of Railisms and you will find yourself in familiar waters very quickly.
Both technologies are not quite there yet, but there is a lot of hype around them and they will for sure play a big role in Ruby's near future.
As #ndn mentioned, Volt is interesting... But, it seems to me that the part I would adopt would be the Opal core for a front end.
Volt is too opinionated for me.
I would like to add my own pet project to the table, Plezi, which can be both an independent framework and can also run together within a Rails app by using the Iodine server.
I feel that Plezi has a much better balance between 'convention over configuration' and code-freedom. It manages the backend by automatically mapping websocket broadcasts/unicasts to their respective controller and method (broadcast :method, arg1, arg2...) and automatically maps Redis channels to controllers (or global multicasting) for easy scaling.
At the same time, Plezi does nothing for the front end and assume nothing regarding the front end. This is by design, both for better security (doesn't auto-trust incoming network data) and to allow for for the variety of possible clients such as native apps (iOS, android), browsers, scripts etc'... This would be where Opal can come in (or RubyMotion).
I am making a gamer server for an ipad,iphone application.
It is a two-player card game but there could be multiple games going on between any two players.
After going through a lot of forums and blogs, I decided to use nodeJS and mongo-db combination.
Now I am new to both but I have time to learn these things and I have a decent amount of experience in JS.
What I am not sure about is, If my client side is iOS and objective-C stack.
What could be the best approach among TCP,HTTP with REST and WebSockets considering,
Reliable libraries avaliable.
complexity level
performance
In case you feel that I should not be using nodeJS in the first place itself, please point me towards the right direction as I am yet to start.
If you're considering using iOS, WebSockets are a no-go -- I'm sure you don't want to make your whole game out of a single big UIWebView.
TCP: well, that's an interesting question. Plain TCP has generally a smaller overhead than HTTP because of no avket headers/etc. are required, but implementing your own protocol is a much greater challenge that should be mecessary for writing a game and you'll end up with the same pitfalls that of HTTP with regard to speed/performance. Also, the BSD sockets API with which you can do TCP networking on Unix is not obvious to use at first glance. However, if you decide to use TCP, here's my OO wrapper for the API: http://github.com/H2CO3/TCPHelper
HTTP: ypu should probably choose it. It has a great history, it's a very mature protocol, and there are quite a few high quality C and Objective-C libraries out there for it. Cocoa (Touch) has the NSURL* kind of Objective-C classes and you also have libCURL for C.
On server side, you also might want to prefer HTTP as modern servers implicitly and automagically support it and you don't have to mess with the protocol to send a message, instead you simply say
<?php echo "Hello World"; ?>
Again, if you want to dig deeper, you can use WebSockets at server side if you deicde to use plain TCP.
I hope this will help.
As it is evident that AJAX based chats do not scale, so what would you use for chats? Custom servers? Or any other methods?
Since with Rails each chat connection will take lots of memory, it won't be feasible to even have Rails run for each message. What do you recommend for use here?
I also tried to implement a sample chat app with AJAX (in built Ajax.updater) but it didn't workout. I'm sure there might be some good ajax solution.
But since this is based on server push technology, try Juggernaut (http://juggernaut.rubyforge.org/). I personally haven't tried, but it seems like it's good.
Or else consider web sockets (in HTML5) if possible.
People often use Evented Ruby for handling problems like this https://github.com/eventmachine/eventmachine one of the examples in a talk I went to at railsconf 2010.
For example http://playtype.net/past/2009/3/11/mini_an_eventmachine_clone_of/ is a evented ruby implementation of an irc bot
Unfortunately your post is based on a false premise. AJAX based chat certainly can scale, you just have to do it the right way. Juggernaut 2, for example, uses Node.js to handle many concurrent connections. You're right, you won't be able to handle 10,000 connections on a single server. That's what load balancing is for.
Do you have some data based on quantitative testing (aside from your own qualitative conclusions)?
Why create any kind of custom server for chat? IRC has been around for quite a while and is tried and tested.
The real question here should be about client-side implementations rather than trying to reinvent the wheel server side imo.
I'm trying to write a scalable interactive chat application for an existing high traffic website. It needs to be scalable on day 1, and chat's concurrency and multi-broadcast issues make it a tricky thing to scale.
My initial plan was to write the whole thing in rails and refactor the chat server into erlang later.
Although I am an experienced PHP dev and sysadmin, both node.js and RoR are new and extremely alien technologies to me, so I could use a little help understanding the core concepts and applications in this scenario. With so many new technologies, it is hard to understand them all.
Firstly, I recommend you review http://ajaxim.com/. The software is a pre-packaged version of what you want that relies on Node JS (far easier than rolling your own).
If you still want to write something yourself and have no experience with either technology, I recommend you review some introductory materials:
Node JS and Rails
The two sources are not free but will give you a quick one hour crash course on each technology.
You can also have a look at http://pusherapp.com ! This is if you want to implement a chat app right away.
If on the other hand, you want to implement one all by yourself, Node.js + Socket.io is your best bet. However, if you want chat rooms and stuff, have a look at this:
http://github.com/shripadk/express-juggernaut-demo
This demo app uses Express.JS framework and Juggernaut 2.
I would suggest going for only Node.js if you are building apps that require high concurrency. Its fairly easy to implement a chat room using Node.js compared to other server-side languages (mainly thanks to modules like socket.io). The event-driven architecture of Node.js makes it really easy to implement such stuff. The only catch with Node is that you have to think everything asynchronous! If you are good at Javascript then Node.js should be easy to learn.
I am a newbie to Erlang and am trying to make a switch to Erlang for our latest project. Since this is going to be a real-time chat (long polled) system for file sharing on the fly, I realized after a bit of digging around that Erlang would be the most appropriate choice, because of high concurrency, plus people also suggested to use Yaws since it can handle upto 50k parallel connections.
Although, it sounds awesome, but since I am a newbie (both to erlang and comet applications), I am unable to understand the right technology stack / architecture of how this would work. Also, because of relatively less documentation, I am unable to figure out how the individual pieces would fit together (web server, application layer, DB, message queue) for such an application. The application is going to run off a desktop client only (no web presence required), and so we need to build a REST api for the functionalities.
It would be great, if someone could point me in the right direction to proceed.
Thanks
Nitrogen has a very slick Comet feature built-in. It will work with the three most popular Erlang web servers, including the one you're already considering, YAWS.
Nitrogen doesn't do anything in particular about data storage. It's not one of those web frameworks that insists on managing the DB for you. You're free to use Mnesia or whatever else you like. If this bothers you, you might consider Erlyweb instead. It doesn't do Comet for you like Nitrogen does, but it's more of the manage-everything-for-me sort of web framework.
You could use:
ejabberd as the XMPP server
mnesia as the database
YAWS as the WEB server
Message Queue : you can implement that in Erlang or use an enterprise solution such as RabbitMQ
The all new Zotonic application may inspire you. It's a webapp running off mochiweb for HTTP service with webmachine for the REST API. And it's using good ol' PostgreSQL as database.
It has comet support implemented.