Add schedule query to Graphql

[ChaseC99]

This PR implements the schedule query and establishes the CourseOffering type.

Test Plan

Verify that the following queries work as intended

{
  schedule(year: 2019, quarter: "Fall", department:"COMPSCI", course_number: "161") {
    title
    id
    offerings {
      year
      quarter
      instructors
      final_exam
      max_capacity
      meetings {
        time
        building
        days
      }
      num_section_enrolled
      num_total_enrolled
      num_on_waitlist
      num_requested
      num_new_only_reserved
      units
      restrictions
      status
      course {
        title
        id
      }
    }
  }
}
{
  course(id: "I&CSCI32A") {
    title
    offerings(year: 2019, quarter: "Fall") {
      year,
      quarter,
      final_exam,
      instructors,
      max_capacity,
      meetings {
      	building,
        days,
        time
      },
      num_section_enrolled,
      num_total_enrolled,
      num_new_only_reserved,
      num_on_waitlist,
      num_requested,
      restrictions,
      section {
        code, comment, number, type
      }
      status,
      units,
      course {
        id
        department_name
      }
    }
  }
}

Verify that the following queries throw an error. We do not support offerings on large nested lists from allCourses or an instructor's history

{
  professor(ucinetid:"pattis") {
    course_history {
    	offerings {
        final_exam
      }
    }
  }
  allCourses {
    offerings {
      status
    }
  }
}

[ChaseC99]

So this is a start for the schedule query. There is still a decent amount that needs to be done before it is merged. I've noted some of my TODO items on the PR.

A few other things I wanted to mention:

• We should consider downloading old websoc data and putting it in a sqlite db.
  Since the data from previous terms are static and won't change, there is no need for us to query websoc every time. We should store that locally. Having it in a local db would also allow us to do more complex lookups, such as showing every course a professor has taught (currently queries are restricted to just one year/quarter). Idk if clients would want that info but maybe it would be worth the effort ¯\(ツ)/¯

• This scheme file is getting BIG!
  After this PR, I think it's time to split the schemas up into separate files.

[ChaseC99]

Right now it will throw an error for each item in a nested list. So a client could end up with several dozen of the same errors lol. It's good that we have this in place because we don't want to send websoc several dozen requests. But I think we could clean up how we're presenting the error to the client.

TODO: only send one error back to the client.

[ChaseC99]

Honestly, just gonna leave this for now. Haven't been able to find a way to do this.

[ChaseC99]

Not sure if I'm happy with these field names. They seem really long...

TODO: find better names

[ChaseC99]

@devsdevsdevs @Maybe14:
Can y'all take a look at the courseOfferingType fields and see if the names make sense to you?

[tisuela]

What exactly is the difference between section_enrolled and total_enrolled? I'm assuming section_enrolled is for the, well, section LOL, like a lab. And total_enrolled is the total amount enrolled in the course (Like ICS 31 taught by Professor Kay).

[ramanxg]

For CourseOffering type for a schedule and course query, is the output supposed to behave differently for the different queries. I noticed that for the schedules, the arguments for the offering field is ignored.

This was the query I was testing it on:

# Write your query or mutation here
{
  schedule(year:2021, quarter:"Spring", department:"COMPSCI", course_number:"161") {
    id
    offerings(year:2020) {
      year
      quarter
      instructors
      final_exam
      num_total_enrolled
      max_capacity
    }
  }
}

Just wondering if this is the intended behavior. It's definitely better to not have a user write the same query over again, so I do agree, but it was unclear to me that this was the case. It could be mentioned in the documentation for graphql playground or on the generated graphql docs.

Also, I was looking over the schema.js file and 100% agree the file is way too large and hard to read, and would be very helpful if separated.

[ChaseC99]

Just wondering if this is the intended behavior. It's definitely better to not have a user write the same query over again, so I do agree, but it was unclear to me that this was the case. It could be mentioned in the documentation for graphql playground or on the generated graphql docs.

The arguments are completely ignored for offerings under the schedule queries. I agree that's confusing... This happens because both queries share the same Course type. I'll look into potential solutions, maybe we could do something with parent/child classes (?)

[tisuela]

Just wondering if this is the intended behavior. It's definitely better to not have a user write the same query over again, so I do agree, but it was unclear to me that this was the case. It could be mentioned in the documentation for graphql playground or on the generated graphql docs.

The arguments are completely ignored for offerings under the schedule queries. I agree that's confusing... This happens because both queries share the same Course type. I'll look into potential solutions, maybe we could do something with parent/child classes (?)

Regarding including in Documentation, I can look into explicitly stating it on GraphQL playground. I think having more guidance on the playground (like a header made up of comments) was a feature previously requested. But other than that, the only other place we can state this behavior is on the MkDocs

[tisuela]

naming looks good!

[tisuela]

What exactly is the difference between section_enrolled and total_enrolled? I'm assuming section_enrolled is for the, well, section LOL, like a lab. And total_enrolled is the total amount enrolled in the course (Like ICS 31 taught by Professor Kay).