Rails%203%20In%20Action

Pagination
show 50 tickets per page. This will lessen the load on your database, but not completely
eliminate it. That would only be possible if you were to run no queries at all. You could
do exactly that if you cached the output of the page, or even just the part of the page
that showed the list of tickets.
The first process involves saving a copy of the page in the public directory, which
would then be used to serve this page. Any action on tickets, such as creating one,
adding a comment, or changing a state would then wipe this cache and start afresh.
The second process is slightly different. Rather than storing the fragment as a file
on the system, you will store it in memory and then access it through a key.
Finally, by adding indexes to key columns in your tables, such as foreign keys, you
can greatly speed up the queries it runs too. If you had 10,000 tickets in your system
and you wanted to find all the tickets which had project_id set to 123, an index
would help speed up this process.
We’ll show you examples of all of these approaches in this chapter, beginning with
pagination.
16.1 Pagination
We’ll discuss two different kinds of pagination here. The first kind paginates the interface
that users can see, as shown in figure 16.1.
If this project had a thousand tickets, it wouldn’t make sense to show all 1,000 at a
time. It would also be terribly slow, because the database would have to retrieve 1,000
records. Rails would then have to instantiate 1,000 Ticket objects, render 1,000 tickets
to the page, and send back that massive chunk of HTML.
The second kind of pagination has to do with your API. Back in chapter 13 you
wrote the beginnings of the ticket API, and we promised you we’d revisit it in this
chapter. Inside the Api::V1::TicketsController’s index action you have this
innocuous-looking line:
respond_with(@project.tickets)
Again, if the database’s tickets table contains 1,000 records for this project, it will
have to send all of them to Rails. Rails will then have to instantiate 1,000 objects, parsing
them all to JSON or XML before sending them off
to the user. All of this would happen with each
request, and if you were getting a lot of requests it
would bring your application to its knees.
By paginating the result sets in both of these situations,
you can change your application to return
only 50 tickets at a time, which would theoretically
make your application respond 20 times faster than
if it were returning 1,000 tickets. Let’s begin by
installing a gem called Kaminari that will help you
with pagination. Figure 16.1 Tickets for a project
435