Best way to implement delivery confirmation/read status

[Kingdutch]

My client is receiving messages in two possible ways:

• In an initial query to create an overview
• Through a persistent subscription

I'd like to send out a mutation when the messages are received (delivery confirmation). As well as when they are first displayed (read status). I'm trying to figure out the best place to trigger such a mutation.

I think read status modification should always happen in the displaying components. However I feel that triggering a mutation at the start of a component render may not be a great thing to do.

Delivery confirmation I'd prefer to handle in the caching layer since all data flows through it so it knows best when something was delivered. However, I'm not sure whether it's considered bad practice to trigger requests from the cache layer (or quite the best way to approach it).

Ideally in either scenario I'd prefer to perform the change in a single request (although they can be separate mutations).

I haven't been able to find any existing literature on this subject in GraphQL in general, so would be happy to hear any thoughts on the subject.

[JoviDeCroock]

Let's tackle this hypothetically, in this scenario we have TextBubble, when a TextBubble finished rendering we are aware the user seen this:

const TextBubble = ({ id, text, read }) => {
  const [, execute] = useMutation(READ);
  useEffect(() => {
     if (!read) execute({ id })
   });
   
   return text;
}

useEffect only fires when a dom-commit happens. Another way to go about this is with a callback, we aggregate the unread message ids and when a user would tap the input-component we'd mark them as read.

I honestly don't think this should be a concern in an exchange/cache since this doesn't accurately follow along with the React-layer if we're talking a suspsenseful or concurrent world.

[kitten]

There's actually a really common solution that's much more clever that a lot of chat applications use.
You store a "read pointer" or a "read timestamp". Any message that has been created sent before this timestamp will have been read.

Every time a user then enters a chat you check the latest message against the timestamp. You can then see whether their "last read timestamp" is older, start a timer, and send a mutation to update this timestamp (hence you get a free denounce really easily)

The sender then only cares about a single field to compute what's been read and each participant only needs to send a single mutation that's easy to manage.

[Kingdutch]

That's actually a really good idea :) I could still abstract that to per-message read status on the back-end if I need it. Since it's not problematic if a lot of messages share the same read time. (We anticipate some scenarios where it's useful to know if individual messages are read).

I suppose I can do something similar with the delivery time/state.

[kitten]

It basically depends a lot; but generally speaking a single mutation with a read timestamp is very easy on an API and no batching is required. On the backend you can always mark all past messages as read, which in SQL ends up being quite trivial, but on the other hand there's nothing stopping you from only storing the last read timestamp per conversation, if your data model has an entity for conversations. If it's just messages and the relationship is a 2-N one and no entity for chats exist and only for messages then of course the backend will have to abstract more. Things get tricky in this scenario in converting the multiple timestamps back to a single one however, depending on how the frontend handles it.

If the front end also receives the read receipts then the update becomes larger and they payload required to update read messages just grows linearly

[Kingdutch]

Yeah we foresee some need for having per-message visibility on these things in the future. So we already built around a concept of a message receipt.

I think with the information from both of you I have enough handles to figure out a solution. Thanks!

[momakes2]

@Kingdutch You can see many of these patterns for building a chat app on telegram.org and its client API docs TDLib: https://core.telegram.org/tdlib/getting-started

For ideas around API design (where I learnt the method Phil mentioned) see https://core.telegram.org/methods and click around to see data types.