Implement backend pagination for GET /listings

[anders-schneider]

Issue

Addresses #56

• This change addresses the issue in full

Description

This change changes the parameters and return type for GET /listings such that results are paginated. The parameters now include page and limit fields, and the returned object includes both an array of Listings and metadata about e.g. which page of listings this represents, how many total listings there are, how many listings per page, etc.

The pagination implementation uses skip and take when building the SQL query, and those correspond to SQL's OFFSET and LIMIT, respectively. typeorm actually sends two queries as a result: a first to ask for all the IDs of listings that are in the specified range, and a second to get all of the data (including all of the data in JOINed tables). (And, this change adds a third SELECT COUNT(*) FROM listings; query in order to populate the pagination metadata, but that should be fast.) The hope is that, although this change means more SQL queries to the database, the overall time to retrieve listing data is faster since we don't have to retrieve all of the JOINed data in a single query.

This change also adds a couple tests and fixes a couple places in the frontend so that they understand the new paginated-listings return type.

Type of change

• New feature (non-breaking change which adds functionality)

How Can This Be Tested/Reviewed?

$ cd backend/core
$ yarn test:e2e:local
$ yarn test listing

Also, if you run the code locally and point your browser to localhost:3100/listings, you should be able to see the new paginated listings result.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have reviewed the changes in a desktop view
• I have reviewed the changes in a mobile view
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• I have assigned reviewers
• I have updated the changelog to include a description of my changes

[willrlin]

Also, change the title of the PR to imperative and remove your username, as if it were the first line of the CL.

[anders-schneider]

Thanks for the comments @willrlin ! I closed the conversations that I felt were resolved, and left the ones that you may have follow-up on open - let me know? And I changed the PR title, thanks for catching that!

[abbiefarr]

This change seems to break both the partner portal:

and the resident portal:

For the partner portal, I'm hoping it's an easy fix in sites/partners/lib/hooks.ts. I have to look more into the issue with the resident portal.

[abbiefarr]

Also I believe that whenever the backend api changes, we need to regenerate the client with yarn generate:client

[abbiefarr]

I fixed the errors with the public and partner portals, with the default values they display all the listings as they did before. I also ran the client library codegen, which generated some changes I expected and others I didn't expect and can't really explain.

PTAL at the newest commit, the issues were with some objects being "undefined", but I'm pretty unfamiliar with typescript so I'm pretty skeptical of the code I wrote.

[willrlin]

Seems fine to me. As for the codegen, hopefully it was just a bit out of date. Maybe we should set a presubmit check to ensure that the generated version matches the PR version?