Social Timetabling planning:
Date & Time | 4/06/2023 8:30pm - 10:20pm |
Participants | Jared, Manhua, Raiyan |
Agenda
CSE Auth SSO system:
wont need validation for credentials
send user to auth system and get code, send user back to you for token/code
oidc flow (open-standard)
When the auth system is ready:
Just replace google’s identity URLs with CSE one
Replace the API to get user information with cse one
sign in with google, but sign in with cse
session handling will be handled by us where we need to validate whether user is logged in
OR
link our session handling to the cse session handling
Overall Recommendations
Don’t use cookies to store timetables
Encode current data structure (selectedClasses, selectedCourses) in links
But in the future planning to mutate the timetable:
links may break
Have TypeScript schema for our data structure to validate the structure
Event Link Recommendations
Proper link that opens Notangles instead of a base64 string
And asks them whether they want to add it to their timetable
Storing JSON data with base64, not the most efficient because not very scalable
Can do instead: protocol buffer (wire encoding)<-- base64 that
Like Google calendar
Tech Stack Recommendations
tRPC instead of GraphQL and dealing with REST APIs
Current tech stack: NestJS, Prisma, SQL is fine
Quick Schema
interface Timetable {
id: uuid;
classes: Class[];
}
interface Class {
}
interface User {
id: uuid (sourced from the auth service)
timetables: Timetable[];
friends: User[];
primaryTimetable?: Timetable;
}
interface Timetable {
courses: Course[];
selectedClasses: Class[];
name: string;
id: uuid;
}
interface Course {
id: course code;
availableClasses: Class[];
name: string;
faculty: string;
offeringTerms: Term[];
}
interface Class {
id:
// you will need to figure out what data you want a course to have
}
encode Timetable interface into link
To-Do
Rest of Jared’s beautiful diagram:
: )