I'm building a web application where users can sign up, add twitters feeds that they want to follow and their stream will update as the feeds they're following receive new posts.
My go to platform is Laravel. However, I can't think of the best way to implement the live update aspect of the site.
I would use an AJAX function that is called periodically (every 30 seconds for example) but as the number of users increases this method as it's drawbacks.
I've looked into HTML5 Server Side Events but IE isn't supported unfortunately.
What would be the best way to implement this functionality within a Laravel App?
Thanks,
Nick
You have two options :
Streaming ( Websockets )
Long polling
You can read more about websockets here :
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
And you can read more about long polling here :
https://www.quora.com/Why-would-HTTP-long-polling-be-used-instead-of-HTTP-Streaming-to-achieve-real-time-push-notifications
In short :
websockets run on a different port than your usual app, so accessing all your assets can be a bit strange(depending on your system architecture).
Long polling is a very long http request that can last up to several minutes, instead of sending a request every 30 seconds, you send it every time the server returns a response. this means that if the server took 5 minutes to return a response, you're only sending a request once per 5 minutes. (for example, there's no reason to alert the client that nothing changed at all, so you can sleep(30) and try again)
As a side note, Unless you need real time data, I think long polling is much easier to implement and use with a framework such as laravel.
you can use pusher or node.js for realtime.In laracast you will find a video how to do that https://laracasts.com/series/intermediate-laravel/episodes/4
I use Pusher for real time data, is extremly easy to use and exists a Laravel package.
https://pusher.com/
https://github.com/vinkla/pusher
Related
We are developing a free, open source Google Reader alternative at http://reader.pykih.com and the code is at http://github.com/pykih/reader
When a user signs up or adds a RSS feed, we add the feed url to the database and then ask a DelayedJob to fetch articles from that RSS url. This typically takes few seconds to minute or two, depending on the DelayedJob queue. Many users have complained that RSS feed is not being fetched at all when in reality it is being fetched. All that the user has to do is refresh his own page. We wrote a message there, yet users are complaining.
Can anyone point us in direction towards - what is the best way to design a Facebook or Google style "Loading" (icon in yellow) functionality and once loaded it automatically adds the entries to the screen without page refresh.
Thank you in advance
If I understand correctly, you basically want to update the user's view of the page while it's still open, in real time. (At any rate, that's what Facebook and most Google products do nowadays). This technique is usually called server push - information is pushed from the server to the client, instead of having the client request (pull) information from the server.
There are multiple ways to implement server push.
You could use AJAX to 'reload' the page every ten seconds or so. This is very easy to implement, but not realtime at all, and could cause unneeded load on your server. It works with all browsers.
You could use EventSource, a relatively new format supported by Firefox, Chrome, Safari, Opera and others (but not IE). It's a very simple format and easy to implement. EventSource is one-way communication only: it sends events from the server to the client, not in reverse.
You could use WebSockets, probably using a library like EventMachine and a WebSocket library. WebSockets allow fast bidirectional communication, but it's more complex than EventSource and only the newest IE versions support it.
You could use a commercial service like Pusher. Pusher is easy to integrate and fast, but not free. Browser compatibility is great, though.
The options differ primarily in the amount of client support (do you need IE support?) and the amount of Ruby integration you get.
I am working on a project which is built on Springs MVC and Google App Engine with Objectify.
The major functionality of this app is: If someone posts something new to the Datastore then it should be auto published to the browsers to which it is connected without refreshing the page content. Basically it is a news like site. The data sent to browser is REST APIs based JSON Data.
For implementing this functionality I thought of using the following ways:
AJAX : I thought of using AJAX call in every 2-3 minutes to get updated. But this solution doesn't seems to be feasible as there are many datastore read operation due to many AJAX calls from many browsers.
Web Socket : This concept is pretty new to me. I am not aware of this thing. Some pusher.com uses this technology for establishing such connections.
Now I need your suggestions, using which of the two above or I am also open to other solutions.
Google app engine does not support web sockets, however it supports something similiar called the channel api which works on older browsers as well. This may not be feasible depending on how many people you will have connected (channels cost 1c per 100). Channels also have some caveats: https://developers.google.com/appengine/docs/python/channel/overview#Caveats
As for using Ajax - if you cache the response in memcache and flush the key every 3 minutes then you won't be doing any data store reads unless a new instance is fired up or the key expires.
What is the difference between all three? They seem to do the exact same thing. Why and when would you choose to use one method over the other?
AJAX and websockets do similar tasks — they both establish a communication channel to a server. Web workers have nothing to do with either of them, they are just separate threads of JS execution.
AJAX is more mature than websockets — it has been around much longer and has a much wider browser support. AJAX is request-oriented — you make a request to the server, the server responds, and the connection is closed. Websockets on the other hand establish a persistent connection to the server, over which you exchange multiple messages in both directions.
Webworkers are useful if you want to perform a processor intensive task without blocking the browser interface.
They are not same. But one can use them together to build advanced application.
Ajax: As abbrevation States is asynchronous javascript and xml.. is used to load the content dynamically from the server upon called.
Websockets : Websockets is the feature defined in HTML5 . As wikipedia states "WebSocket is a protocol providing full-duplex communications channels over a single TCP connection." so this is mainly used for real time communication such as video call, live chat etc..
WebWorkers : this feature is also defined in HTML5. This is basically used to make bring multi threading feature in Javascript. Since javascript is a single threaded programming language , it breaks or pause whenever i.e heavy calculation tasks are done using it. to overcome this breakage , Webworkers are added to javascript.
You can perform Ajax and Websockets inside Webworkers . however you cannot manipulate DOM using webworkers due to security reasons.
They are not the same.
Ajax: It is a way of interacting with a web server asynchronously from a UI renderer
Web Sockets: An HTML5 feature using which you can interact with any Socket server extending the reach of the browser
Web Workers : Another HTML5 feature that helps you do multi-threaded programming from a web browser using Java Script
Ajax & Websockers are siblings.
Webworkers are completely different.
AJAX
The best example of AJAX is Google's search bar - suggestions appear as you type, but the current webpage is not redirected or refreshed! (10 years ago this was amazing, not so much anymore). This is AJAX in action.
AJAX uses what's called a "request" and "response" model: you ask a question, and you receive an answer from the 'server'.
AJAX allows webpages to talk to "servers" behind the scenes, allowing you to update a webpage without navigating away from your URL. Back in the old days of the web, if you wanted to show different content on a webpage, users would have to navigate to a different URL: not any more. This concept has been taken to the next level with single page apps and applications (like React, Vue, Elm etc.).
Websockets:
With websockets, your web-page talks to your server (as with Ajax), and your server responds - except you do so like you're talking on the phone. There is a "connection" between your users and your server. This "connection" is not there with AJAX: in that case, you have a simple request and a response coming back from the server.
In other words, if you wanted to stream stock market data, constantly updating it to your users: it would probably be better to use websockets, than AJAX.
Web-workers:
Use When you need intensive calculations - if you were to ask a web-page to calculate Pi to 100000 decimal places: that might take a while. The web-page might freeze, and you might lose $$. The intensive calculations can be done in the background, without freezing your webpage. People using your site can do other things - e.g. click around, while waiting for the result in the meantime.
Hello everyone
I just wanted to know if I use AJAX for my chat engine, will it crash my server or it will work fine for a traffic of about 1500 people at a time ??
Also suggest me some way to make automatic ajax request to update the contents of chat box. How much delay between consecutive query should be set so that it doesn't cause my server to overload ???
Thanks in advance :) :)
Depending on your requirements, you might want to look into WebSockets. At a local hacknight, we produced a simple chat system pretty quickly using http://faye.jcoglan.com/. It's a pub sub service that you can use javascript on the client side to subscribe to a specific channel. Then it's just a matter of coding the front end to work with the input and output.
I have found very little on this topic. I'm trying to work out a way to synchronize pages cross-web without having to constantly reload pages to get new information, since the rate at which this would be necessary would cause the page to be outrageously slow.
The flow I'm thinking is this:
User A alters info displayed on Page A.
Page A sends info to server.
Page B checks server for new info every 10ms or 100ms.
Page B loads Page A's new info.
I can see AJAX as being sufficiently fast to retrieve info from the server, but have found no way to send data to a server without having to refresh every 10ms, which, even using an iframe to avoid reloading the whole page, seems far too slow to me. Correct me if I'm wrong.
So my question is, is there any way of which I am unaware to do what I am attempting? I have seen methods involving a Java server applet, but that's a bit above my head at the moment. If that's the only way, I'll learn it, but I'd love to avoid that if possible.
There are two possible interpretations of what you wrote, the first which seems to be what you've actually said is that you want to know how to send data with an Ajax request, the second is that you want to know how to push unsolicited data from the server to the client.
Ajax can easily add data to a request it makes - just add query-string parameters, or make a POST request and use XHR's send method
Use comet - i.e. keep open a long-lived connection and send data only when there is something to send.
One of the possible way to implement what you want is to use Comet technology. For example - facebook uses it to interact with their servers.
If you are retrieving info fast using AJAX, then you are also sending info fast with AJAX...
GET requests are still telling the server something. For example, lookup RESTful web-services.
You could use updater of Prototype.