I am working on a website, and want to allow my user to work without having to click save to manually save their data (similar to how Google Docs allow you to work without having to press save). I was able to achieve this by using a on change event in JQuery and using AJAX to post to the server every time that event occurred. The only problem is that this results in MANY requests to the server. How do I achieve the same result, while reducing the number times requests are sent to the server.
Any help would be greatly appreciated!
Thanks!
The terms you are looking for a “throttle” and “debounce”. There are numerous solutions (e.g., jQuery plugins such as https://code.google.com/archive/p/jquery-debounce/ – disclaimer: I haven’t used jQuery in years, and therefore have no experience with this plugin), but reading a little bit about it, this is not hard to implement it yourself. In case you use RxJS (not likely in a project that still uses jQuery), there are also methods debounce and throttle in it.
Have you thought about using a timer? For example you could still use the on change event, but instead of transmitting on every change you could start a count-down and only if the user didnt typed for for example 10 seconds you transmit.
Related
I would like to have a page where a restaurant can log in and see all of their current reservations/take-out orders, and I want this page to automatically update when someone (from another computer) makes a reservation or places an order. The idea is that the restaurant would leave this page open at all times to show their current status. What is the best way to do this? Can it be done without refreshing the page?
I wasn't even sure how to refer to a setup like this, so I wasn't really able to find much using Google. Is there a word for this type of setup?
I am using rails, and I am considering using AngularJS for the front end. Any suggestions?
There are two approaches to solving this.
The first, oldest, simplest is that your webpage contains some javascript that will poll the server at regular intervals (e.g. every 10-30 seconds), to check if something has changed and then add the changed data (e.g. reload a partial).
The second approach is a bit cleaner, and it allows the server to push the changed data to the connected clients, only when it is changed.
There are a few available approaches/libraries for this:
use websockets
use pusher
use juggernaut The author of juggernaut had deprecated it, in favor of using HTLM5 SSE (server sent events). Read more.
The advantage of using polling is that it is easy, works on every browser, but you have to write more code yourself, you will put some kind of load on your server, even if data has not changed (although the load is minimal).
The push-technologies are newer, work very clean, less code is needed. But some work only in newer browser (most of the times not really an issue), and some require extra support/setting up on your server-side.
On that note: pusher is really easy to get started with, and if your load is limited, it is free.
There are still a lot of others, but this should get you started in the right direction.
I have been working with ajax for a while now, and I have used it to do a lot of nifty jobs.. But then my recent challenge has been on push notification.
I want to implement a site that would not need to make a call to the server every period of time, but rather would make a call to the server only when there is an update on a particular DB field, and I want to implement this in PHP, javascript and/or jquery or any other technology for the web. I do not have any idea as to how to go about it, or if it is even possible.
I would like directions on where and how to start, Thanks all.....
Since WebSocket support isn't quite there yet, you would want to fall back on long polling. There already seems to be a jQuery plugin for this:
https://code.google.com/p/jquery-graceful-websocket/
A nice slide on this subject can be found here http://www.slideshare.net/ffdead/the-html5-websocket-api
To implement WebSockets in PHP, have a look at https://code.google.com/p/phpwebsocket/
I'm working on a tool that will require 'listening' for a response from the server.
Currently I've got the page using JQuery to request a URL and respond based on it's output.
I do that every couple seconds.
However, as there will likely be hundreds of people using the tool all at the same time, that could be a pretty big server load.
Is there a way I can create a 'listener' that will notify the loaded pages when a change happens instead of constantly querying the server?
I haven't really been able to find much on Google (probably not searching for the correct thing) so hopefully someone here will know exactly what I'm talking about.
Thanks in advance for your quick responses!
You are looking for technologies named Comet or server push. There are several different implementations of this problem, typically involving long-running, but idle HTTP connections. Check out Atmosphere (in Java) or various other libraries.
Also make sure to have a look at web sockets (new HTML5 technology).
See also
COMET javascript library
Alright, Here it goes:
I'm currently implementing a software which autorefresh/autopull/autoreload the data to keep the screen live by using AJAX.
This is actually working, but I know I´ve used the simplest approach which is:
SetInterval (javascript)
Call the Refresh Method over and over each n seconds.
Read the Json Data, rebuild the HTML and update it.
This can also be done by just calling a SetTimeOut (javascript) and the end of the AJAX request.
In the refresh method I internally check that it´s not being called simultaneously, etc.
However... this is the simplest approach, it works but, in slow computers, firefox and ie, I can see this activity sometimes freezes the browser, and I know this might not be necessary because of the AJAX call, but how "intensive" is the javascript operation overall... but, after running a profiler, Overall javascript (using jquery by the way) seem to be fine. Also if I disable the autorefresh, the browser wont freeze by short seconds in slow computers.
I decided to investigate how several of the majors AJAX applications works out there.
Facebook for instance.. they do a request all the time, every N seconds, interpret the JSON and update the screen, but, google docs... I can seem to find any request.. This is maybe because: they are just telling the javascript debugger engine that they do not want their request to be logged??, or, are they using another approach to the refresh dilemma?
I read in another answer here at stackoverflow, that Google Docs keeps an open connection..
Can this be the answer? http://ajaxpatterns.org/HTTP_Streaming
What do you guys know about this?
Just as a side note, the application I´m developing is meant to be accessed by thousands of users at a time, and I know the JavaScript refresh routine only tells a little part of the history, but the Server Side Application and the database is currently supporting such a load according to the stress tests I did by using several thousands of virtualized stations. I just want to know what you think about the client browser problem specifically.
Regards and
If you are still reading this..
Thanks you for your time.
I suspect they're using WebSockets. Browser support is flaky, so your mileage may vary with this approach.
You may also want to look at APE (ajax push engine), which is a decent implementation of long polling with a client/server architecture.
You can read up on Long Polling. But then you'll have to handle dropped connections etc.
Understanding that if someone had JavaScript disabled the site would not work then is there any other reason not to do this?
I am in the design phase of a new site and want to make it easy to change the server code without having to change the UI - just like a form.
This is using Python server side.
One problem, arguably, is that Ajax techniques break the back button.
By making all of your calls to the server Ajax calls, the user loses their ability to 'go back' to a previous view. Facebook exemplifies this. Click the back button on Facebook, generally, does not take you to the previous view you were presented with.
In addition, it is more difficult for a user to bookmark their current view of the site. This can make it difficult for them to share what they are seeing with others and can make it difficult to debug problems that users see; rather than just sending you a URL to recreate their problem, they have to figure out the numerous steps they took before they spotted a problem.
Personally, I think the best place for Ajax is for updating small segments of a page. If you have a page that is changing more than, say, 50%, you may want to rethink the sole use of Ajax
Potentially yes, here are two items that come to mind.
Search indexing: this would have profound impact on what content on your site search engines like Google can index. Because the crawlers do not execute any AJAX script when reading your page.
Performance: Too many AJAX calls can actually hinder performance and page load response times. AJAX should generally be used to update only specific parts of a given page if at all possible. If you can emit the majority of content in the first page get request you should, period.
For a desktop-like rich web application, I would say that the all AJAX approach is acceptable.
However unobtrusive JavaScript and progressive enhancement may be a better strategy for most categories of public web-facing interfaces.