MA6 - In-App Chat

[davidtaing]

Introduction

Problem statement

We want to allow Customers and Service Providers to communicate with each other in app. The main benefits is to make it easier for us to learn how our app is being used. In addition, in-house communication will make it easier to moderate abuse between the different parties.

Goals

• Customers and Service Provider should be able to communicate with each other during the quotations and jobs processes.

Non-goals

• Voice and video chats are not in scope.
• [Not Now] Image chat.
• [Not Now] User presence and User is Typing indicators.

*Non-goals marked with Not Now can be considered for further tickets.

Prerequisites

This will require the tasks, quotations and jobs features to be completed.

Features built on top of Stripe such as Customer / Provider Onboarding and Payments are not required.

[davidtaing]

Proposed solution

DRAFT

High Level Design

• Client: Next.js Client
• API Server: Supabase / PostgREST. Accessed via the supabase client.
• Websocket Server: Supabase Realtime

This solution relies on a Websocket server to push updates to the client.

Message Send

Message Update / Receive

Notes:

• Getting messages is oversimplified in the diagram and I have not yet figured out how I want to access them.
• The specific event that is sent by the websocket server has not been decided yet. This will either be an event indicating message created or thread updated.

Database Schema

TODO

• Need to add a diagram.
• Need to talk about how we want to query results. e.g. Get messages belonging to this thread.

TODO - Messages Table

• Message ID should be some sort of ordered data-type.
  • Given that we are working towards the MVP, we will go with the serial autoincrementing integer type for now.
  • Should be ordered to increase the likelihood of data clustering. This should improve write performance as the database is better able to batch operations on indexes.
  • Ordered UUIDs such as v7 UUIDs can be considered in the future.

TODO - Threads Table

• Having a latest_message_id field is a key piece of this solution.
  • This will enable us to fire events indicating thread updated instead of message created.
  • In addition, this could simplify searching for the latest message. Since this is 'precomputed", we can skip scanning the table.
  • This will be updated when via a database trigger on a message insert.

Sending Messages

Sending messages can be handled by the Supabase client & PostgREST so no additional API endpoints are required.

This can be achieved with the following code snippet.

const message = {
  content: "Hi, I can do this for $300.",
  recipient_id: <recipient_id>,
  sender_id: <sender_id>,
  sent_at: new Date().toISOString(),
  thread_id: <thread_id>,
 };

await supabase.from("messages").insert([message]);

Getting New Messages

The query for getting new messages can be represented by the following SQL snippet.

SELECT * from Messages
WHERE thread_id = :thread_id
AND id > :last_message_id

This relies on the message.id field being some sort of ordered ID.

Getting Updates via Supabase Realtime (Websockets)

Pros & Cons

Pluses

• ➕ Reduced server load as the server can now push events to the client.
• ➕ Better UX for the client due to messages being more realtime.

Minuses

• ➖ Supabase quotas offer limited concurrent clients.
• ➖ Increased complexity due to having to manage websocket channels and active conversations.
  • Probably have to manage active conversations with polling anyways.
• ➖ Still have to add polling as a fallback, albeit at a longer frequency (e.g. 30+ minutes)

Chat UI

For the new Chat UI, we'll use the chatscope/chat-ui-kit to bootstrap our UI.

To get an idea of what it looks like, check out their demo at https://chatscope.io/demo/chat-friends.

In the future, we can look into migrating the UI to Radix UI Themes. The value is debatable but this could make sense as a collection of onboarding tasks.

State Management in React

TODO

• Will most likely have to use the reducer pattern for this. Vanilla useReducer is an option.
• Can look into Zustand
• Would also be worthwhile to look into immutable state management. Immer is a suggestion from the Zustand docs.

Thinking about using converting arrays to objects as hashmaps (todo: reword).

const state = {
  messages: {
    // convert the messages array to an object
    messages_id_1: {...},
    messages_id_2: {...},
    messages_id_3: {...},
  },
  threads: {
   // convert the threads array to an object.
    thread_id_1: {...},
    thread_id_2: {...},
    thread_id_3: {...},
  },
}

// This will make it easier to apply updates.
const newMessages = {
    messages_id_2: {...updated message 2...},
    messages_id_4: {...},
    messages_id_5: {...},
}

const newState = {
   messages: {
     ...messages.
     ...newMessages
   },
   threads: state.threads,
}

Some care will need to be taken to prevent re-renders due to recreating the root state object. Not a fan of slapping useMemo on everything. We'll look around.

[davidtaing]

Alternative solutions

DRAFT

Discussion on alternative solutions will be focused on how we get updates from the server. Message Send, Chat UI & Chat State Management will remain the same across the different solutions.

High Level Design

Message Send

Getting Updates

Getting Updates via Polling

Write up about polling.

Pros & Cons to Polling

Pluses

• ➕ Simplier to implement.

Minuses

• ➖ Given that we hit the server at a specific interval
  • Generally more noisy and may use up more resources.
  • Handling requests for polling means that the server isn't processing normal traffic.
  • Each request is probably hitting the database. If you are not careful, you might do a table scan.
• ➖ Polling is a type of pull communication, so the client doesn't know when there is a new message.

Notes

• Updating once per hour may be acceptable for our users based on my conversations with the team.
  • This is the reason that was initially my proposed solution. This is not my preferred solution.
  • I may switch between polling and websockets as my proposed solution.

[davidtaing]

Implementation and rollout plan

1. Tech Spike / Proof of Concept

The original proof of concept will be implemented in this pull request / branch

• 12

A simplified database schema was used for tasks, quotations and jobs, so this pull request will not be compatible with the current implementation.

2. Wait for Prerequisites to be Completed

See original post for more information.

3. Setup Dependencies

Setup dependencies as a separate pull request since PR #12's package.json file contains a 1500 line diff.

4. Setup Database

Similar to the previous, we'll setup database migrations and generated database types as a separate pull request.

5. Implement Chat

Finally, we'll implement chat using PR #12 as inspiration.

Note: Since we don't have any users, we can be more flexible with deleting database migrations.

[davidtaing]

Glossary

Application

• Customer: Individuals who initiate tasks on the platform.
• Service Provider: A person or company that undertakes work. For example this could be a tradesperson like an Painter or something more generic like a tutor or a cleaner.
• Tasks: These represent pieces of work ranging from home repairs, gardening, cleaning or any other task they require help completing.
• Quotes: These are bids made by service-providers on a task.
• Jobs: Refer to Tasks where a Customer has agreed to go ahead with a Quote. This name has not yet been finalized yet; the naming may change.