Building this out with a Frontend and micro service architecture

[rkho]

I'm having too much fun naming services. Not perfect/final.

Clan Lunches, MVP: == Frontend ==

• User signup, authentication w/ Github
  • First name
  • Last name
  • Cohort
  • Email
  • Github
  • Work address
  • Available days
  • Distance willing to travel
  • Walking
  • Public transit
  • Driving
  • Skype/remote?
• Modify profile, login w/ Github
  • Email
  • Work address
  • Available days
  • Distance willing to travel

== Database, SQL ==

• Users table
  • ID
  • All information in signup
  • Latlong table ID
• Latlong table
  • ID
  • Users table ID
  • Latlong (either as a pair, or one colum for each)

== Database, Redis ==

• MeetingsWanted store
  • // Why Redis: This information gets run once a week and gets deleted afterwards. Again, not needed long-term.
  • Users table ID
• Distances store
  • // Why Redis: Much easier than a table full of columns. If a user modifies their address, we'd have to go through here and wipe their distances as well as the mapped value of their distance to other users that they've matched with before
  • Users table ID : object of other users and their distance
• Pairings store
  • // Why Redis: Again, not long term. Pairings will differ from week to week.
  • Users table id : array of pairings
• NumMeetings store
  • // Why Redis: A key/value store for this type of information is much more valuable than keeping a table full of columns when certain users may almost never pair with each other (i.e. HRX in SF -> HRX in NYC)
  • Users table id: object of other users and the number of pairings

== Backend, Services ==

• Scheduler
  • Emails all users once a week that have an availability of greater than 0
  • Do you want a meeting? If yes, we'll update the MeetingsWanted store with their info. Otherwise, ignore.
  • Emails users without availability at all once a month to remind them of the service
  • Emails the pairs once they've been determined
• Matchmaker
  • First, creates pairings for users based on the following:
  • Available days. No use in pairing people whose schedules will never match
  • Distance willing to travel. We need to find out if there's a midpoint between their addresses, or if they're close to each other.
  • Then, decides on the best possible pair which is determined by:
  • Number of matches (users with only one match should get that match instead of losing it to someone with multiple matches)
    • If they only have one match, we should email them and mention that they might want to try and expand their distance
    • Additionally, we don't want to always pair the same two alum together here
  • Number of meetings this pair has had (least = more likely to match)
  • Sends info to Scheduler to email pairs.
• Ingestor
  • Takes signup information and adds it to our database's Users table
  • Latlong is calculated through Cartographer first
• Modifier
  • Takes modified profile information and updates our Users table.
  • Cartographer is run if work address changes
• Cartographer
  • Calculates the LatLong of users.
  • Ingestor runs this during signup
  • Modifier does as well if the address changes for our user
  • Also calculates distance between two users

== Things to think about ==

• Validate users as actual HRX?
• Sister/partner school students?
• Current cohorts?
• Suggested venues?

[dsernst]

This is awesome.

• What are the benefits & consequences of using Redis?