feat(study-rooms): serve slots data

[laggycomputer]

Description

Adds study room slots and availability to study room endpoint.

As previously implemented in the data pipeline, availability is available in on the days between the day of the current time in UCI's timezone (America/Los_Angeles) and exactly 3 days later, inclusive. Data is updated every 2 minutes.

This PR simply exposes that data. We use ISO 8601 dates (most precisely, z.string().datetime({ local: true })) which are given with the Z indicating UTC but should be interpreted as being in UCI's timezone. We ask Postgres to interpret the TIMESTAMP NO TIMEZONE in America/Los_Angeles and format as zoned ISO 8601, avoiding adding a JS timezone library.

Note: The slots field on returned study rooms is now guaranteed to exist. This is not a breaking change.

We use a materialized view to precompute the JSON structure of the response. The refreshing of this view is relatively light and is done as part of the study room and slot scraping process every 2 minutes. However, it is not completely trivial; see below demonstrating that it produces a significant speed improvement per request which will accrue over time. This design decision is a database schema change. Since we have this JSON structure beforehand, we need only SELECT with conditions when serving a response.

Related Issue

Feature update as requested in #46. Also closes the inconsistency raised in #74 since study room data was one of the offenders and is within the jurisdiction of this PR. It doesn't.

Motivation and Context

be me
want study room slots
no study room slots

mfw

How Has This Been Tested?

Tested with Postman on a local deployment.

Screenshots (if appropriate):

Old screenshots (before timezone correction):

REST is functional:

GraphQL is functional:

New screenshots (latest):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code involves a change to the database schema.
• My code requires a change to the documentation.

[andrew-wang0]

As discussed, the study room slots start and end times being displayed like UTC time while being in PST/PDT could be confusing.

We've resolved to use true UTC time instead 👌

[laggycomputer]

To be precise, I'm going to specify the correct UTC offset in the response.

[laggycomputer]

Without fully redoing tests, the correct offset is now specified:

We add moment-timezone with this PR; this is a change in the convention of this project to use vanilla Date and may require some further work to re-standardize.

EDIT: This PR now uses Postgres to handle timezones.

[laggycomputer]

Demoting to draft; I've just remembered Postgres supports JSON aggregation and benchmarking should be done to determine whether it is a better (faster) approach.

[laggycomputer]

Some benchmarking:

• Aggregation of slots in JS takes 72.8±7.5ms per request.
• Aggregation of slots in SQL on every request takes 76.8±7.6ms per request.
• Aggregation of slots in a SQL materialized view updated on every scrape takes 61.4±6.4ms per request (p < 1e-4 improvement over JS).

Given the following conditions:

• Mostly quiet local system.
• Middleware responsible for validating keys was disabled to reduce variance. Ratelimiting middleware was disabled to avoid spoiling the tests with 429s, since they by nature need to execute 1000 consecutive requests successfully.
• Testing method was hyperfine --warmup 10 -m 1000 "curl localhost:8787/v2/rest/studyRooms", i.e. n=1000 with 10 warmup runs.

We currently used a materialized view for this PR. Promoting out of draft status now that this analysis is complete.

[andrew-wang0]

Wow mindblowing work on this, will dig in to test 😎 👌

[andrew-wang0]

Looks good! A few format errors but other than that it's good to go

[andrew-wang0]

Another quick nitpick

[andrew-wang0]

Looks good!