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.
Related
I know this will be closed question but I can't find what I want so I need to ask pros over here.
What is the best option for real time content in laravel app like messages, notifications and even loading new post as example.
Besides using pusher or other services.
Something like nodejs and socketio but
what are the best
options for laravel apps?
If you are wanting to take advantage of Laravel's Broadcasting functionality then going with a supported driver is likely best to get you started.
Which means that if you don't want to use Pusher then it is a combination of Redis and Socket.io.
Our small team doesn't have a dedicated dev-ops team, so we went with Pusher and have had a good experience with minimal server config. We do also use Redis for pubsub communication between a couple of microservices, some api throttling management, and of course queues. It might be worth noting that if you are a Laravel Forge user it provisions Redis out of the box for you too.
You have to think of your software needs.
Pusher comes with a Free Tier, and its easier to implement than Socket.io
Setting up Socket.io will come with some learning curve, you may want to expend your time on other functionality of your project. But hey its free right? unless you consider time more valuable, which is almost always the case when it comes to programming.
With Pusher, you can quickly start your project, focus on other less trivial requirements.
Socket.io may save you money, but only once is running.
If your project doesn't consume the free tier completely, it's a no brainer.
I am redesigning a web application which previously has been rendered server side to a Single Page Application and started to read about websockets . The web application will be using sockets to have new records and/or messages pushed to the client. I have been wondering why most pages which make use of sockets don't handle all their communication over the socket. Most of the times there is RESTful backend in addition to the websocket. Would it be a bad idea to have the client query for new resources over the socket? If so why - other than that a RESTful api might be easier to use with other devices?
I can imagine that using websockets would probably not be the best idea in case the network connection is kind of bad like on mobile devices, but that probably should work quite well with a reasonable connection to the web.
I found this related question, however it is from 2011 and seems a little outdated:
websocket api to replace rest api?
No, it won´t be a bad idea. Actually I work in an application that uses a WebSocket connection for all what is data interaction, the web server only handles requests for resources, views under different languages, dimensions .. etc..
The problem may be the lack of frameworks/tools based on a persistent connection. For many years most of frameworks, front and back end, have been designed and built around the request/response model. The approach shift may be no so easy to accept.
Coming back to this question a few years later, I would like to point out a few aspects to illustrate that having all your communication through websockets does have its drawbacks:
there is no common support for compression. You can easily configure your webserver to compress http requests and browsers have been known to happily accept compressed responses for years, however for web sockets it is still not that easy (even though the situation has improved)
client frameworks often are build upon commonly used standards like rest. The further away you move from frameworks expectations, the less addons or features will be available.
caching in the browser is not as easy. By now this goes a long way, reaching into the realm of offline availability and PWAs.
when using technology, that is only used by a subset of users, it is more likely to find new bugs, or bugs might take longer to fix. And if it's not bugs, there might be an edge case somewhere around the corner. This isn't an issue per se - but something to be aware of. If one runs into those things, they often easily take up quite some time to fix or work around.
I was just wondering, How do comments appear instantly on Facebook? For example, when I'm on my profile and my friend comments something on my post, I can instantly see it. Is it AJAX? Or Queuing system? If I want to do the same thing, what do I do?
Thanks
I'm not exactly sure how facebook has implemented their system.
but it will either work with websockets, AJAX or a comet server.
If you want to have the same effect there are a lot of different techniques you could use,
but I would recommend looking into node.js and maybe even the now.js plugging, which allows for realtime updates via websockets. It even has support for older browsers, so if the browser does not support websockets, it will do a fall over to either a comet server implementation, AJAX or an iframe.
Basically websockets allow for better control over when data should be sent or received from and to the server since it constantly listening to the socket, so you only send data when required and same for receiving data as well, where with an AJAX approach you had to make a call every X seconds.
It's extremely easy to setup on a linux environment, and there's ample documentation to get you started.
It works with javascript and is build on the Google V8 engine, so if you've ever worked with OOP Javascript, you should be able to pick it up relatively easy.
LINKS:
http://nodejs.org/
http://nowjs.com/
You'll want to look into PHP sockets
Actually, its long polling according to this answer (which also explains how to verify or see if its changed since the answer):
How does Facebook fetch live updates
I'm working on the design of a web app which will be using AJAX to communicate with a server on an embedded device. But for one feature, the client will need to get very frequent updates (>10 per second), as close to real time as possible, for an extended period of time. Meanwhile typical AJAX requests will need to be handled from time to time.
Some considerations unique to this project:
This data will be very small, probably no more than a single numeric value.
There will only be 1 client connected to the server at a time, so scaling is not an issue.
The client and server will reside on the same local network, so the connection will be fast and reliable.
The app will be designed for Android devices, so we can take advantage of any platform-specific browser features.
The backend will most likely be implemented in Python using WSGI on Apache or lighttpd, but that is still open for discussion.
I'm looking into Comet techniques including XHL long polling and hidden iframe but I'm pretty new to web development and I don't know what kind of performance we can expect. The server shouldn't have any problem preparing the data, it's just a matter of pushing it out to the client as quickly as possible. Is 10 updates per second an unreasonable expectation for any of the Comet techniques, or even regular AJAX polling? Or is there another method you would suggest?
I realize this is ultimately going to take some prototyping, but if someone can give me a ball-park estimate or better yet specific technologies (client and server side) that would provide the best performance in this case, that would be a great help.
You may want to consider WebSockets. That way you wouldn't have to poll, you would receive data directly from your server. I'm not sure what server implementations are available at this point since it's still a pretty new technology, but I found a blog post about a library for WebSockets on Android:
http://anismiles.wordpress.com/2011/02/03/websocket-support-in-android%E2%80%99s-phonegap-apps/
For a Python back end, you might want to look into Twisted. I would also recommend the WebSocket approach, but failing that, and since you seem to be focused on a browser client, I would default to HTTP Streaming rather than polling or long-polls. This jQuery Plugin implements an http streaming Ajax client and claims specifically to support Twisted.
I am not sure if this would be helpful at all but you may want to try Comet style ajax
http://ajaxian.com/archives/comet-a-new-approach-to-ajax-applications
For a pet project, I have been looking for a web chat script capable of running potentially tens of thousands of users simultaneously. I don't want to use any kind of applet or browser extension, so on the client side, it should be simple Ajax. On the server side I'm pretty much open to anything.
I'm not looking for bells and whistles, a simple text-only chat is more than enough, as long as it supports a number of 'channels' or 'rooms' simultaneously, and a very large number of users.
When I first started researching the chat scripts out there, it seemed like the only viable option was to run an IRC server and just build a web interface on top of that. I know I could get good performance and stability with that setup, but could I get better performance by using something else?
Any ideas?
You might want to check cometd
I believe there are some chat scripts already using cometd.
I have no idea regarding stability tho.
You can have a look at Jabbify.
Not sure about the rooms and channels part, but it is built on the AJAX and MVC model.
I am going with Twitch.me, which is based on node.js