Roommate Matching Implementation

roommate_matching.md

Roommate Matching Implementation

We could implement our current roommate matching functionality in three different ways with the release of the new app.

Elixir Bot

To make this work, we need to adjust our current RoomBot code to talk to Ejabberd server instead of Twilio.

Current Implementation

1. Mobile client initiates a roommate matching request by caling the initiateRoommateMatching mutation
2. A request is sent to the elixir bot by the rails server
3. Per user, Elixir bot keeps the progress status for the roommate matching questions
4. Based on user's state machine, roombot uses the Twilio channel to convey the next question to the mobile client
5. Mobile Client receives the possible answers for each question from chatbot through a set of attributes options and questionId
6. The user will choose an answer for the question
7. The answer will be received by chatbot
8. The chatbot will update user_roommate_answers table (owned by Rails database)
9. The process happens for all questions
10. When the process is done, mobile client can query for the results of roommate matching

Needed Adjustments

Chatbot will need to use ejabberd instead of twilio as messaging carrier.

1. A roommate matching channel needs to be created per user on ejabberd side.
2. All roommate matching questions will be sent over the roommate matching channel.
3. All roommate matching answers will be send over the roommate matching channel.
4. Clients will need to update to handle new Message Type

In this approach, the communication between Elixir chatbot and Rails server will stay the same.

Cons

1. Adds unnecessary complexity
2. Needs a series of collaboration between elixir-bot/ejabberd-server/Rails
3. Probably needs involvement from Manish
4. Elixir bot needs write access to user_story_answers table which is owned by Rails app

Pros

It works!

Ejabberd Bot

The same functionality could be implemented as a ejabberd bot.

Suggested Implementation

1. Mobile client initiates a roommate matchig request
2. The request is received by ejabberd
3. For each user, the bot keeps track of most recent answered question_id
4. Based on user's state machine, ejabberd conveys the next question to the mobile client
5. The possible answers for each questions are received by mobile client from ejabberd server
6. The user will choose an answer for the question
7. The answer will be received by the bot
8. The bot will issue a redis job and informs the Rails server about a new answer for a question for a certain user. For example: { user_uuid: '1111', question_id: '13', answer_value: 5 }
9. The process happens for all questions
10. When the process is done, mobile client can query for the results of roommate matching

Pros

• No need for a separate elixir bot
• The logic could be encapsulated inside ejabberd server

Cons

• Still complex to implement
• Needs a lot of collaboration between ejabberd and rails
• Roommate matching questions and database IDs needs to be stored in ejabberd side
• ejabberd needs to keep track of user's progress in answering the questions

Rails API

Instead of using the chat platform to convey the questions and answers from/to Rails server, the mobile clients will talk directly to Rails server.

This is the way we implemented roommate matching 2 years ago. It requires a change in the way that roomate matching question are presented and also the way the answers are received from the users. Probably we need to move to a form-based approach instead of a bot-based one.

Suggested Implementation

1. The mobile client receives the list of questions from the Rails. (Retrieving all the list at once would suggest that we would not be able to pick up where we left off. Alternatively, we could call a query that would return currentRoommateMatchQuestion or something equivelant.)
2. It will present the questions to the user in a form-based fashion and it will require an answer for each question
3. For each answer, mobile client will call a GQL mutation to let the Rails server know about the new answers.
4. At the end of the flow, user will see a list of roommate matching results

Pros

• No single point of failure. Mobile clients will talk directly with Rails servers and there is no need for a middle man
• Simplest to implement

Cons

• It's not a chatbot
• Eliminates reusing the exsiting Chat View Controller. Would need to either create a "Mock" Chat view controller or go with a new design.

---

Complexity of Implementation from backend perspective (higher-effort to lower-effort)

1. Elixir Bot (large effort)
2. Ejabberd Bot (large effort)
3. Rails API (small effort)

Complexity of Implementation from mobile-client perspective (higher-effort to lower-effort)

1. Rails API (medium effort)
2. Elixir Bot (medium effort)
3. Ejabberd Bot (small effort)