Im trying to make a chat app with spring and flutter and i was wondering if sockjs is really a big deal since these days every browser supports websockets and there is no need for fallbacks and also for me there is no sock js library in flutter .
So is sock js even useful in 2020 ?
Yes your logic is correct, chrome and mostly all browsers use websockets now. Although you'd be loosing some functionality from sockjs but say for chat app it won't be needed
Related
We are going to develop rest server for our application (and all logic is on client javascript).
So we thought to use Phalcon php, but we also need to create realtime chat system, which is much more easy to do using node.js. This made us think about using node.js instead of phalcon
Unfortunatly, we are not good expirienced in node.js, we love phalcon for its performance and internal beauty.
The quiestion is, did anybody compare phalcon and node.js performance? May be it's better to use node.js only for long polling chat requests, but i dont like when project is connected with so different tools.
You are trying to compare two different things IMO.
node.js has a lot of power and flexibility but so does Phalcon. If you want to create a chat application with Phalcon, then you will need to implement some sort of polling mechanism in your browser that would refresh the chat window every X seconds. Getting/Inserting the data from the database will be Phalcon's job. Javascript will be used to do the polling i.e. refresh the chat page every X seconds.
The problem with this approach is that you might be hitting your web server every X seconds from every client that has the chat application open - and thus refreshing the chat contents, even when there are no messages. This can become very intensive very quickly.
node.js has the ability to send messages to the subscribed clients instantly. Web sockets can do the same thing I believe.
Check this video out, which will give you an idea of how this can be achieved easily:
https://www.youtube.com/watch?v=lW1vsKMUaKg
The idea is to use technologies that will not burden your hardware, rather collaborate with it. Having a "subscription" notification system (such as sockets or node.js) reduces the load on your application since only the subscribed clients receive the new messages and no full refresh is needed from the chat clients.
Phalcon is great for the back end with its speed and it can be used to construct the message which in turn will be passed to the transport layer and sent to the client. Depending on how you want to implement this, there are plenty of options around and you can easily mix and match technologies :)
as #Nikolaos Dimopoulos said, you're trying to compare two different things.
But here is my advice, while you're experienced with PhalconPHP framework, and you want to benefit from Phalcon speed and performance, you can implement the web app in Phalcon FW, and the chatting system in Node.JS as a service.
If your web application "The Phalcon app" needs to push messages from the backend, you can use http://elephant.io/ library for that, I have done this before with Yii framework and Node, and it's working perfectly.
My advice is to use what you already know, experimenting with nodejs just for the chat application.
Mainly because you said you do not have experience with it, so, because the chat app is something a lot of people made you'll find plenty of examples.
By doing so you will learn a lot from node and might even think about migrating from Phalcon if it suits your needs, using the features offered by expressjs for example.
I would not choose one over the other based on performance.
I'm about to start a project for a client that has lots of data that needs to be real-time.
There are two mobile apps that I will be building with trigger.io, as well as a web UI, and all of these need to stay in sync.
I plan to use socket.io's WebSocket implementation with my Node.js backend for the webapp & mobile apps. This will work great on iOS and modern web browsers.
However, Android's webview does not support websockets at all. And it would simply destroy the mobile app user's data plan if socket.io used its long-polling fallback on Android.
I was wondering: is there any possibility of an implementation of Java WebSockets for trigger.io Android, then exposing that to the WebView? There is a simple implementation for phonegap
I suppose I could write a trigger.io plugin for it - but I want to be sure before I jump in to this project if this is feasible / not too hard to write a plugin for.
I used trigger.io long ago, but not since all the fanciness came out like native plugins.
If using an HTTP fallback solution isn't an option (I'd do some calculations to determine if a streaming or long-polling solution would really "destroy the mobile users's data plan") then the best solution to add WebSocket support would probably be a trigger.io plugin.
At Pusher we used a Java wrapper in PhoneGap in order to get our JavaScript library to work. However we've since added HTTP fallback so I wouldn't recommend anybody use this now. The project is here:
https://github.com/pusher/pusher-phonegap-android
The problem with the Java wrapper here (we use websocket-android-phonegap) is that it doesn't support SSL connections (if I remember correctly) and it hasn't been updated for a long time.
With that in mind when we created the Pusher Java library (which supports Android) we used the WebSocket client in Java-WebSocket because it's being actively developed and supports SSL connections. I'd recommend it.
I'd be interested to hear about the support that https://github.com/mkuklis/phonegap-websocket provides.
We are currently working on an app that uses pusher.com to maintain a list of available people on our chat application.
Unfortunately, some of our users have IE < 10 (ie no websockets) and don't have flash, so pusher.com will not work. Also, pusher is becoming more and more expensive for our usage (pusher is more for few connections with lot of data going through and we're doing the opposite!)
So I'm looking for an alternative to pusher (either hosted or self-hosted) that will work on IE7+ with or without flash.
So far, here is what I'm considering:
XMPP/BOSH
socket.io (self-hosted)
pubnub
As for the scale, we will probably have to handle 100+ messages per second and 10000 concurrent users. Nobody here has ever played with socket.io (or bosh), and we do not wish to have too much maintenance work (ie deal with many servers and such). So 2 or 3 self-hosted servers is ok, 10+ isn't.
Any thoughts?
Unfortunately, some of our users have IE < 10 (ie no websockets) and don't have flash, so pusher.com will not work.
This is incorrect. Pusher (who I work for) provide fallback for older browsers. HTTP-based fallback has started to be released to go alongside the existing Flash socket fallback. So, older versions of IE were already handled with the Flash socket fallback but the HTTP-based fallback will give near 100% browser coverage.
The November 2012 issues of the Pusher newsletter has the following:
We've always loved WebSockets, and since the beginning they have been our primary transport mechanism. While they are still the best way of sending data between applications, we do sometime have to resort to various trickery to negotiate troublesome proxies. By popular demand we are soon going to be bolstering our legacy support by adding HTTP based transport to our existing fallback options.
We have already deployed some provisional endpoints which apply in a set of limited conditions, and we'll be continuing the expansion of this feature over the next few months. If you want to have early access to this as a beta user, please get in touch with support#pusher.com.
In terms of cost:
Also, pusher is becoming more and more expensive for our usage (pusher is more for few connections with lot of data going through and we're doing the opposite!)
Have you contacted Pusher support explaining your use case? Discounts may be available.
So I'm looking for an alternative to pusher (either hosted or self-hosted) that will work on IE7+ with or without flash.
There's a realtime web tech guide which has a good list of realtime web technology solutions (it's on my site and I maintain it). If you want to support IE then a solution which offers HTTP-based fallback is the safest bet.
I would personaly go with socket.io. It supports Internet Explorer 5.5+.
It supports various transports and uses the most-appropriate one to ensure browser compatibility without having special code to work with each browser. Here is the list of transports from the website:
WebSocket
Adobe® Flash® Socket
AJAX long polling
AJAX multipart streaming
Forever Iframe
JSONP Polling
You can see the full list of browser support here.
As for BOSH, here is a discussion on BOSH vs Websockets. If you go ahead with BOSH, you will be missing out on Websockets functionality that modern browsers support.
You should check out ScaleDrone as an affordable alternative to Pusher.
I am in great dilemma as to use html5 websockets or signalR for a chat we are going to integrate into our asp.net mvc3 application
My dilemmas
1.Why to use signalR if it implements longpolling?
2.Isnt longpolling bad?
3.websockets and longpolling completely different?
4.Only IIS8 supports websockets?
5.Can i save the chat data into SQL database using Html5 websockets?
6.Isnt there a workaround to make websockets work on IIS7 and higher versions(i will be using chrome browser only)
Thanks for bearing with me
Why to use signalR if it implements longpolling?
Answer: to enable support for old browsers or to have a higher level of abstraction over data transfer implementation details. If you definitely will use the version of chrome that has a websockets support - use websockets (good explanation here).
Isnt longpolling bad?
Answer: actually it is not the best (see link above), but better than nothing for old browsers.
websockets and longpolling completely different?
Answer: they are quite different (again, see answer above), but there is smth in common for them (they both require a connection).
Only IIS8 supports websockets?
Answer: if you want to use pure .NET framework - yes, only IIS 8, and .NET 4.5. But you can use another websockets server (see workaround below).
Can i save the chat data into SQL database using Html5 websockets?
Answer: websockets is only a protocol to send data, so literally using it you cannot perform any action except of transferring data. However you could, say, have a token that will be send to server and will mean "save all previous data to DB". Or you could have more complex scenarios based on different kind of messages like inplemented in socket.io for node.js.
Isnt there a workaround to make websockets work on IIS7 and higher versions(i will be using chrome browser only)
Answer - yes, just do not use IIS, but another websockets server implementation (e.g. Fleck - has nice support for "old" browsers supporting webseckets) and run it alongside IIS as a separate process for example.
SignalR can support websockets if IIS and your browser support this, if not it uses longpolling.
Using SignalR will save you a lot of time reinventing the wheel, they have proven that you can create a good chat website with it.
Hope it will solve all your queries.
4. Only IIS8 supports websockets?
SignalR supports IE < 8 with Json2.js. Just get it with Nuget install-package json2
Make sure you add a reference to json2.js BEFORE signalR.js
I bet WebSockets are much faster.
So if I want to use lots of ajax continuously, WebSockets are recommended as an alternative?
It's two different technology things.
With AJAX client just send request to server and wait to response.
Websocket is HTML5 implementation for Comet technology, the idea is push information from server to client.
Ajax is slower because the overhead.
But Ajax is more compatible, Websocket is currently a bit experimental and it is not widely supported by most browser.
I think is not a issue of speed, is a issue of comunication and real time process
If you're in regular need of asynchronous data transmission I'd say you should try out websockets, it's really easy to use. One problem is - because of the early stage - the websocket interface might change (which has happended already) and render your web application unusable until you update your code.
Definitely WebSockets!. During my last internship, we used WebSockets together with Erlang to build a chat app for feature phones. Not only was it resource-efficient, it was also faster,
and really realtime - connections are always open, until either end closes.
And oh, they are experimental but works well on Chrome, Firefox, Android and iOS.
The only problem was with parsing data with BB which was because of the library we were using, so we rewrote the library's data parsing algorithm and it worked.
We tested on only these platforms.
You can checkout Socket.IO which improves upon the raw implementation of WebSockets.
Visit this link for some quick demos: http://socket.io/#how-to-use