I have a rails app that shows users posts. Users posts can be sorted in many ways, paginated, categorized, etc. I am doing all of these clicks over ajax.
However, everytime I click a category or a sortby param or a new page, it loads the ENTIRE request again and then returns it in the way specified. Is there any way to cache my first results and THEN sort, paginate, categorize quickly?
In order to enhance the performance, a better way is to use memcache. If you have memcache installed and implemented in your rails app, you can cache that query for a certain period of time without actually querying the database again instead it will fetch directly from memory again, thus it improved performance greatly. You may want to check out https://github.com/nkallen/cache-money.
This is a question of using AJAX vs a non-AJAX javascript implementation.
When using Ajax, the question you should ask yourself is, does this action require more information or logic from the server? If the answer is no and you can do it using only the information you have already loaded on the client browser, you should try and implement it using Javascript.
In this case, there are plenty of solutions for javascript sorting out there. For example, if you want a simple table-like sorting (your table could be invisible) you could use something like this plugin: http://yoast.com/articles/sortable-table/
If you're looking for a more custom solution, you could write the javascript by hand, this post: Sort <div> elements using jQuery gives a good starting point.
Hope that helps!
Related
Our SQL Server database has a huge number of data in different tables (millions of records) and we are populating the data using paging in the UI. Data is dynamically added and updated. Now I am planning to implement realtime filtering/searching of the data. The UI will have a text box where user types search keyword and the rows in the grid should be refreshed based on the search string as a typeahead functionality. I am thinking to use azure search as one of the candidate for implementing this functionality. But we are not on cloud yet and I have to justify my team if we had to go through this route.
Are there any other products or methods that can help in achieving this? I am still doing research on this. But if anyone has already implemented a solution like this, I would like to know more about your recommendations.
I recently started using https://datatables.net, and it's been a good experience.
Otherwise, you'll probably have to roll your own solution that keeps track of page and filter criteria on the client side and makes Ajax calls whenever they're altered. Your endpoint would need to take the page and filter as parameters, perform the necessary query of the data, and return the desired records.
I have a Rails Application where I want to present user with a sequence of Questions in a particular order. A user cannot proceed to the next question unless he has answered the previous one.
Here are some design issues I need help on for an efficient implementation:
To fetch a list of questions for a user I need to make an expensive
db call. Once for a new session, the list if fetched I simply want the
user to see the questions in a particular order starting from the
first question. If the user had attempted some questions in
a pervious session he will jump to the question he last left off. How
to implement it efficiently? I believe I need caching here.
On rendering the views :
How to render the view for this feature? I can have a controller with
the initial question template. When user attempts the question, should
I have question-answer options text updating with AJAX? Do I have to
use jquery for the purpose or any Rails helper could be of help here?
Any design help, rails features-gems I could make use of will be welcomed.
My answer is not specific to Ruby on Rails, but it should still work.
First I wouldn't load data that you potentially won't use in advance. If you have 10 questions, and you only show one at a time, then I would just load the first and then once the user has finished the first, go ahead and load the second. No need to load all ten because maybe the user never makes it to question 10.
Assuming the user leaves pre-maturely, you can just make an AJAX call to pick up where you left off.
I would agree that you should cache those questions though.
The steps would look like this then:
First question - loaded via AJAX. Answer and progress saved via AJAX call.
If (1), then second question loaded via AJAX. Answer and progress saved via AJAX call.
Repeat until questions done.
This way you can use user/login information to make an AJAX call to pick up where you left off. I would imagine this would make your database calls much less expensive.
Apologies in advance as I'm sure this topic has no doubt been asked before but I couldn't find any post that answers my specific query.
Bearing in mind that I'm new to MVC this is where I have got to. I've got a project developed under VS 2010 using the MVC 3 framework. I've got a search page which consists of 6 fields and a nested model which itself holds around 3 fields.
I can successfully post all this data back to itself and the data is successfully passed as a model and back agian so the fields keep the data which the user has supplied.
Before I move on to actually using this search criteria on another view a thought hit me. I want to keep this search criteria, and possibly even the search results in memory for the duration of the users session.
The reasoning behind this is simply to save my users time by:
a) negating the need to keep re-inputting their search criteria regardless of how they enter or leave the search page
b) speed up the user experience by presenting the search results more quickly
The later isn't as important as the first requirement.
I've done some google searches and indeed had a look through this site on similar topics. From what I've read using sessions (which I would typically use if developing a PHP site) is a no no. From the reasons I've read as to why you shouldn't use sessions seem valid and I'm happy to go along with it.
But now I'm left in a place where I'm scratching my head wondering to myself what exactly is best practice to achieve this simple goal that could be applied to similar situations later down the line in the project.
I also looked at the OutputCache method and that didn't behave as I expected it to. In a test I set the timeout for 30 seconds. After submitting a search I clicked the link to my search page to see if the fields would auto-populate, they didn't. But then clicking the search button the values in the cache were retrieved. I thought I was making progress but when I tried to submit a new value the old value from the cache came back i.e. I couldn't actually change my search criteria with the cache enforced. So I've discounted this as an avenue to explore.
The last option seems to suggest the use of cookies as the most likely candidate, but rightly or wrongly I feel this isn't the best solution. I would have thought the MVC 3 design pattern would have an easier and recommended method of persisting values. I'm sure there is but I've just not discovered it yet.
I have started to use JQuery and again this has been mentioned but I'm not sure this is right direction to take either.
So in summary my question really comes down to what is considered by the wider community as best practice for persisting data in my situation. Effiency, scalability and resiliancy is paramount as I'll have a large global user base that will end up using this web app.
Thanks in advance!
Pete
I'd just use cookies. They're simple to use, you can persist them for as long as you want or have them expire when the users closes their browser, and it doesn't sound like you are storing anything sensitive in them.
Sometimes at websites all comments or other data from DB is hidden by default. When user click at link like "Display comments" all comments from database are dynamically selected and placed under the content. It must be great for mysql performance, because content is generated only when user excatly need it. I would like to implement this stuff at my app.
I've got one idea to do this so far. Remote action with #comments = Content.comments and next page.insert_html at RJS template. Is it good idea or maybe I should choose different way?
The decision is purely based on the application that you are developing. For example if in case of stack overflow it does not make sense to show only the question and show answer link. But in case of a blog post it may be fine.
In the above situation, I don't think there will be a good improvement in performance by removing the comments of the content on show page. We can achieve the same functionality by making use of javascript methods. Hide the content on page load and show in on client request.
Yesterday morning I noticed Google Search was using hash parameters:
http://www.google.com/#q=Client-side+URL+parameters
which seems to be the same as the more usual search (with search?q=Client-side+URL+parameters). (It seems they are no longer using it by default when doing a search using their form.)
Why would they do that?
More generally, I see hash parameters cropping up on a lot of web sites. Is it a good thing? Is it a hack? Is it a departure from REST principles? I'm wondering if I should use this technique in web applications, and when.
There's a discussion by the W3C of different use cases, but I don't see which one would apply to the example above. They also seem undecided about recommendations.
Google has many live experimental features that are turned on/off based on your preferences, location and other factors (probably random selection as well.) I'm pretty sure the one you mention is one of those as well.
What happens in the background when a hash is used instead of a query string parameter is that it queries the "real" URL (http://www.google.com/search?q=hello) using JavaScript, then it modifies the existing page with the content. This will appear much more responsive to the user since the page does not have to reload entirely. The reason for the hash is so that browser history and state is maintained. If you go to http://www.google.com/#q=hello you'll find that you actually get the search results for "hello" (even if your browser is really only requesting http://www.google.com/) With JavaScript turned off, it wouldn't work however, and you'd just get the Google front page.
Hashes are appearing more and more as dynamic web sites are becoming the norm. Hashes are maintained entirely on the client and therefore do not incur a server request when changed. This makes them excellent candidates for maintaining unique addresses to different states of the web application, while still being on the exact same page.
I have been using them myself more and more lately, and you can find one example here: http://blixt.org/js -- If you have a look at the "Hash" library on that page, you'll see my implementation of supporting hashes across browsers.
Here's a little guide for using hashes for storing state:
How?
Maintaining state in hashes implies that your application (I'll call it application since you generally only use hashes for state in more advanced web solutions) relies on JavaScript. Without JavaScript, the only function of hashes would be to tell the browser to find content somewhere on the page.
Once you have implemented some JavaScript to detect changes to the hash, the next step would be to parse the hash into meaningful data (just as you would with query string parameters.)
Why?
Once you've got the state in the hash, it can be modified by your code (or your user) to represent the current state in your application. There are many reasons for why you would want to do this.
One common case is when only a small part of a page changes based on a variable, and it would be inefficient to reload the entire page to reflect that change (Example: You've got a box with tabs. The active tab can be identified in the hash.)
Other cases are when you load content dynamically in JavaScript, and you want to tell the client what content to load (Example: http://beta.multifarce.com/#?state=7001, will take you to a specific point in the text adventure.)
When?
If you had a look at my "JavaScript realm" you'll see a border-line overkill case. I did it simply because I wanted to cram as much JavaScript dynamics into that page as possible. In a normal project I would be conservative about when to do this, and only do it when you will see positive changes in one or more of the following areas:
User interactivity
Usually the user won't see much difference, but the URLs can be confusing
Remember loading indicators! Loading content dynamically can be frustrating to the user if it takes time.
Responsiveness (time from one state to another)
Performance (bandwidth, server CPU)
No JavaScript?
Here comes a big deterrent. While you can safely rely on 99% of your users to have a browser capable of using your page with hashes for state, there are still many cases where you simply can't rely on this. Search engine crawlers, for example. While Google is constantly working to make their crawler work with the latest web technologies (did you know that they index Flash applications?), it still isn't a person and can't make sense of some things.
Basically, you're on a crossroads between compatability and user experience.
But you can always build a road inbetween, which of course requires more work. In less metaphorical terms: Implement both solutions so that there is a server-side URL for every client-side URL that outputs relevant content. For compatible clients it would redirect them to the hash URL. This way, Google can index "hard" URLs and when users click them, they get the dynamic state stuff!
Recently google also stopped serving direct links in search results offering instead redirects.
I believe both have to do with gathering usage statistics, what searches were performed by the same user, in what sequence, what of the search results the user has followed etc.
P.S. Now, that's interesting, direct links are back. I absolutely remember seeing there only redirects in the last couple of weeks. They are definitely experimenting with something.