I've got a couple projects that were built using hookbox to manage real-time message passing between web clients and servers. Hookbox was great -- it totally abstracted the transport layer, exposing a simple publish/subscribe interface across different channels with an elegant security system.
Unfortunately the hookbox project has rapidly fallen into disarray due to the original maintainer's unwillingness to even put in the effort to hand off ownership. (Grrr!) So it's hard to consider it a viable platform any more.
What's a good platform for providing real-time communication with web apps? Requirements:
Works seemlessly cross browser, using HTML5 websockets or COMET as available. Transport choice should be invisible to application layer. I don't care about ancient browsers (IE6)
Client access from both javascript and server-side systems (i.e. in php / python / ruby) -- this is critical
Provides a publish / subscribe metaphor with arbitrary payloads
Allows clients to see what other clients are connected to a channel, i.e. presence
Fine-grained access control through callbacks to any web application (nice to have)
I've heard that socket.io can do some of this, but I get the sense that it's at a lower layer of the stack. Can it connect to non-javascript libraries? Do auth?
I've had a very good experience with NodeJS and Socket.IO over the last 8 months. The server side component has been very stable for me - I can leave it running with a very high message volume and it's resident memory never really budges above 20MB. So far I've only been able to leave it running for about 4 weeks without terminating the server, but that was only because I needed to update my server side code.
Works seemlessly cross browser, using HTML5 websockets or COMET as available. Transport choice should be invisible to application layer. I don't care about ancient browsers (IE6)
Provides a publish / subscribe metaphor with arbitrary payloads
Socket.IO is also a fantastic piece of software. It under active development, and has a simple pub/sub style abstraction built in using EventEmitter (NodeJS) semantics of 'on' (subscribe) and 'emit' (publish). It is also very transparent on the client side regarding the transport being used. I used it primarily for the straight-up WebSocket support, but it can fall back to Flash based sockets, xhr-polling, and jsonp polling.
Client access from both javascript and server-side systems (i.e. in php / python / ruby) -- this is critical
NodeJS is JavaScript, running on the V8 engine. It has a ton of 3rd party modules that provide nice abstractions as well as interfacing with external components, such as a databases or message queues, among many other things. As far as hitting the system with php/python/ruby, it would work as with hitting any other server. Choose your method of communication (basic TCP/IP, or maybe HTTP POSTs or GETs, or even via filesystem) and NodeJS doesn't really care who is providing the data. Personally, I've implemented a C# client that is working great.
Allows clients to see what other clients are connected to a channel, i.e. presence
It doesn't not have any built in 'presence' logic, though with the built in 'pub/sub' logic already in place in Socket.IO, all you'd have to do is store state on the server so new clients can retrieve existing presence data. I've implemented my own basic pub/sub on the server that retains state, and all together (including the NodeJS server code, and the basic Socket.IO stubs) it was only 50 lines of JavaScript (including whitespace).
Fine-grained access control through callbacks to any web application (nice to have)
Not sure what you mean by 'Fine-grained access control through callbacks to any web application (nice to have)'. The pub/sub event/observer metaphor they have uses callbacks, so you hook specific actions to specific events.
Do auth?
I've had no need, yet, to do any auth for our systems, so I can't speak to it directly. However, if you browse the NodeJS modules you'll notice there are many auth modules available, including LDAP and OAuth, not to mention one module that claims to do "OpenId, Google, OAuth, Twitter, LinkedIn, Yahoo, Readability, Dropbox, Justin.tv, Vimeo, Tumblr, OAuth2, Facebook, GitHub, Instagram, Foursquare, Box.net, LDAP"
Although I haven't tried it yet, I started looking into Pusher for a Node Knockout 2011 entry. In addition to JavaScript, it supports the following non-js clients:
Objective-C
ActionScript
.NET & Silverlight
Ruby
Arduino
If messaging via a 3rd party is a possibility, you can try the service for free using their Sandbox plan (20 connections & upto 100K messages/day) and see if it meets your needs. (I'm a little uncertain about the "presence" requirement, though it may be covered in the docs.)
I recoment using node.js which has a lot of libraries for various things. One library for real time messaging is now.js. I don't have a lot of experience with this but have tried it and I would say it worked well and has everything you said you need.
Related
This has been asked before at
Can I connect directly to a Redis server from JavaScript running in a browser?
(notice my comment)
and
Connecting directly to Redis with (client side) javascript?
but I wonder about something which would have perfect realtime connection. Reading the (a node-redis client) https://github.com/luin/ioredis source I noticed the net part of node`s library is likely containing the kind of functionality we'd need to reproduce in the browser to do this .
Guessing maybe something with hacked together from pieces of webrtc functions could do it ?
Prospective benefits relate to building large distributed app systems infrastructure -- like social media (from comment on first question linked above):
I'm asking this question again, but stipulating we want a 'real' as in realtime redis-client -- not HTTP anything -- operating in the browser. Could build a great realtime 'infrastructure' with just CDN serving assets constituting the client webapp communicating with Redis directly. I want to cut out the unnecessary WebSocket server aspect of the system. All the control logic can be internalised to redis cluster in Lua.
To implement a direct redis-client in the web-browser you need to change Redis itself, so it will expose WebSocket interface. That way you will get the simplest protocol browser is allowed to use.
Other approaches will involve intermediate layers. I think it should be possible to proxy commands via ws-tcp-relay which is pretty fast.
I am new to web development and I just want to know some performance comparison.
I am building a tetris battle game on the web. Most of the game logics are inside of a server, which is built in C++. For clients, I am planning to use cocos2d-js, which is basically javascript.
Players' behavior will affect opponents. First, users' inputs need to get to the server correctly, the server applies inputs to the logic, and it will send a new game state back to clients. Client only needs to represent sprites on the screen.
My original plan was to implement it with TCP socket since it may need low latency. However, I just realized that we don't use TCP socket on the web.
Is it feasible to use HTTP connection for this kind of application?
Should I try web socket?
What are the pros and cons?
You can certainly use HTTP for this but for real-time communication the best option is using websockets.
Raw Sockets (aka, TCP sockets) are not part of the W3C standard.
Even though some browsers have implemented them, I'd recommend avoiding using them unless you don't care about locking your application with that specific browser.
In general, using Websockets will be your best option, they offer the same performance as raw sockets and are easier to use from JS.
Unfortunately, using a C++ server might be more complicated for this, since your server must implement the protocol, you can find some implementations on the internet like this one, for example.
Or, if you want to have a simpler integration with client/server you could try out Node.js to implement your server logic and use the Socket.io library to handle communication, which will also handle incompatible browsers gracefully. Note that Socket.io uses a different protocol, so I don't recommend trying to use it with your current C++ server if you want to avoid doing lots of extra work.
To sum things up
Raw (TCP) Sockets
Pros: easier to integrate with your current C++ server
Cons: browser support isn't guaranteed, not a (web) standard, will need more work for synchronization, communication, etc.
Websockets
Pros: performance on par with TCP sockets, easier to implement client-side
Cons: you might have to do more work on your server implementation
My personal recommendation would be avoiding TCP sockets if possible and stick to the standards.
Edit: Apparently, TCP sockets might end up being a W3C standard, the APIs are still a draft (and a pretty recent one), so I still recommend against using them (latest Chrome has an experimental implementation).
I think #Sosdoc has given the correct answer. The only thing i want to add that a libarary like SignalR can help you very much with the implementaton of websockets. You might want to check out the c++ signalr-qt project on github: https://github.com/p3root/signalr-qt
I've done some research and I've noticed that in a lot of examples Symfony2/AngularJS apps the frontend and backend are combined; for example, views use Twig.
I'd always thought that it's possible (and common practice) to create the frontend and backend separately and just join them by API. In that case if I want to change a PHP framework I will can do it without any problems and it will be enough to keep API.
So what are the best practices for doing it? It would be great if you could explain it to me and even greater if you just give me a link to good example on github or something.
We have been developing some projects using the same approach. Not only I think it doesn't have any "side effect", but the solution is very elegant too.
We usually create the backend in Node.js, and it is just an API server (not necessarily entirely REST-compliant). We then create another, separate web application for the frontend, written entirely in HTML5/JavaScript (with or without Angular.js). The API server never returns any HTML, just JSON! Not even an index structure.
There are lots of benefits:
The code is very clean and elegant. Communication between the frontend and the backend follow standardized methods. The server exposes some API's, and the client can use them freely.
It makes it easier to have different teams for the frontend and the backend, and they can work quite freely without interfering with each other. Designers, which usually have limited coding skills, appreciate this too.
The frontend is just a static HTML5 app, so it can (and we often did) easily be hosted on a CDN. This means that your servers will never have to worry about static contents at all, and their load is reduced, saving you money. Users are happier too, as CDNs are usually very fast for them.
Some hints that I can give you based on our experience:
The biggest issue is with authentication of users. It's not particularly complicated, but you may want to implement authentication using for example protocols like OAuth 2.0 for your internal use. So, the frontend app will act as a OAuth client, and obtains an auth token from the backend. You may also want to consider moving the authentication server (with OAuth) on another separate resource from the API server.
If you host the webapp on a different hostname (e.g. a CDN) you may need to deal with CORS, and maybe JSONP.
The language you write the backend in is not really important. We have done that in PHP (including Laravel), even though we got the best results with using Node.js. For Node.js, we published our boilerplate on GitHub, based on RestifyJS
I asked some questions in the past you may be interested in:
Web service and API: "chicken or egg"
Security of an API server: login with password and sessions
I asked this (voted to be too broad) Question while working my way through a starter book on node. Reading this book, I'm sure I'll learn the answer to this later, but I'd be more comfortable if I knew this up front:
My Question: Can I (efficiently) continue using a usual webhost such as iPage or GoDaddy to host my web application, building and hosting the front end in a simple, traditional manner through an Apache web server, and communicate with a separate Node.js server (my application back-end) via AJAX for queries and other things that I can more efficiently process via Node?
More specifically, would this be a bad programming practice in terms of efficiency and organization? In other words, would it be likely that a large scale commercial application would ever be handled via this method?
Yes, you can separate the front-end of your web application and the APIs that power it. In fact, this is a very common configuration, especially for "large scale commercial applications".
Where you draw the separation line between the two specifically depends on what you are doing, how you're doing it, and what your needs are. Also, in terms of hosting, remember that if you're accessing something server-side across the internet, you're adding extra latency to everything. Consider getting off Go Daddy and using another host that gives you more flexibility, such as a VPS provider.
It's ok. Actually, this is how things shoud be done. You have a backend API on a separate server and lots of apps which are using the API. Just go with Nginx server, check this Apache vs Nginx.
Yes you can use node js as a part of some big application. It depends on wich type of interaction you would like to get. Is it comfortable to you to mix technologies? Then node is pretty good thing to work over web. I've finished a part of big nodejs-ruby-php-c-flash application (my part was nodejs) for very large data mounts. This application have different levels of interaction. Sometimes I use 2 languages at one time to create each part of my application the best for task I'm working on. There is applications that initiate, run and destroy mutiple OS instances. So using of multi environmental application not so hard.
Has anyone an idea for the following scenario?
I have a RIA-Webapplication (realized in ExtJs). What I want to implement is the possibility to use local ressources like card readers or fingerprint readers or other serial devices and filesystem access.
I thought about implementing this with a local websocket service which has to be installed by our customer before using our RIA the first time. When the webapp is loading it should scan the local machine if a websocket service is available and connect to it.
After that, local events (like new card is beeing read or recognized new finger) should be passed to the browser via websocket connection.
Any ideas how to get started with such a solution?
I have made something like that. Besides the obvious things such as read/write/poll data from the card-readers and so on, you would have to either implement everything yourself or, use a library for technology you are going to employ for your web-server. So, if you use a LAMP solution, i think there are some web-socket libraries for PHP that you can use. However, if you do everything by yourself then you have to implement everything from hand-shaking, to creating data packets. I have done everything from scratch by using .NET and it provides a number of useful libraries such as hashing. Java also would be a good option and have those kind of libraries as well. In general if you doing everything by yourself i would say the trickiest thing would be to split the data you want to transmit among various data packet. It is not that hard to do things from scratch. The RFC (https://www.rfc-editor.org/rfc/rfc6455) helped me a lot. Hopefully, this helps.