[MU] Kill unecessary requests

[chibenwa]

Description

We launched the service on MU, so far so good, though the service load is important.

I do believe the frontend needs to do a housing cleaning job to remove unecessary requests and result in a smoother app.

---

Open Folder (critical)

When I open a folder:

• TMail does the required Email/query | Email/get to load the mail entries in it => OK
• TMail resync the email cache with Email/changes | Email/get | Email/get wich is far from essential with a good websocket management!

=> Remove uneeded Email/changes | Email/get | Email/get ? It's useless: we just loaded the list...

---

Page load (medium)

In order to display the spam banner Twake Mail do execute Mailbox/query + Mailbox/get.

We could easily piggy back the spam banner onto the mailbox list side panel loading and save us two requests on application load.

---

Changing flags (absolutly critical)

In the webmail when I update the flags (read / important) it:

• Change the flags then queries it back straight Email/set + Email/get
• Triggers aggressively an email resynchronisation Email/changes | Email/get | Email/get
• Then triggers aggressively a mailbox resynchronisation Mailbox/changes | Mailbox/get | Mailbox/get
• then receives a websocket notification...
• And decides to triggers aggressively an email resynchronisation Email/changes | Email/get | Email/get
• And decides to triggers aggressively a mailbox resynchronisation Mailbox/changes | Mailbox/get | Mailbox/get

I click one button it runs 14 JMAP query (+ the websocket notification)

I know James to be non transactional (yet!) so we cannot say "hey the email state of the websocket notification is the result of our action" - that might come one day - CF linagora/james-project#5366 - but I thing it would be trivial in the front to:

• Change the flags then queries it back straight Email/set - no aggressive Email/get and we assume the action did succeed if James says "update: ok".
• Remove the aggressive resynch...
• then receives a websocket notification...
• And decides to triggers aggressively an email resynchronisation Email/changes | Email/get | Email/get
• And decides to triggers aggressively a mailbox resynchronisation Mailbox/changes | Mailbox/get | Mailbox/get

Down to 7 queries: wooow! If not just 1...

Ah euh and if we failed to sync because EG websocket are not reliable the user can still refresh. Better press sometime the refresh button than run a denial of service attack on the poor poor poor mail server...

---

Moving an email (absolutly critical)

Idem for mail movement...

• We start with an Email/set to move the mail - so far so good
• We aggressively refresh emails with an email resynchronisation Email/changes | Email/get | Email/get
• We aggressively refresh mailboxes with a mailbox resynchronisation Mailbox/changes | Mailbox/get | Mailbox/get
• We do get a websocket notification for a change in the source mailbox...
• We do aggressively refresh emails with an email resynchronisation Email/changes | Email/get | Email/get a second time!
• We aggressively refresh mailboxes with a mailbox resynchronisation Mailbox/changes | Mailbox/get | Mailbox/get a second time!
• We do get a websocket notification for a change in the destination mailbox...
• We do aggressively refresh emails with an email resynchronisation Email/changes | Email/get | Email/get a third time!
• We aggressively refresh mailboxes with a mailbox resynchronisation Mailbox/changes | Mailbox/get | Mailbox/get a third time!

So a wapping 19 JMAP requests for a simple drag and drop. Beautiful DOS.

I know:

• 1. Twake mail generates two notifications: one for the source mailbox and one for the destination mailbox (the event system inherited IMAP single folder structure) CF [PERF] Reliable "newState" for Email/set method james-project#5366
• 2. And Twake mail is non transactional so the newState property is not to be relied on...

Indeed there is backend work here: while (2.) is a mismatch for Cassandra, (1.) could be a refactoring away: publish a list of events and not single events... This means we could collapse the source and destination mailbox together and receive a single notification for source AND destination. See linagora/james-project#5365

But we could also skip the initial resynchronisation.

If front and back does work correctly on this we can go down to just 7 requests if not just one...

---

Websocket PING (important)

Today Echo method is used in order to keep the connection alive. This result in a MASSIVE workload that, really, do not add much value.

Websocket as a native ping. We shall rely on it.

This matter of fact actually do NOT satisfy me at all: it's too violent...

I asked ChatGPT to use websocket ping with your library.

  final channel = IOWebSocketChannel.connect(
    'wss://example.com/socket', // URL du serveur WebSocket
    pingInterval: Duration(seconds: 10), // Envoie un ping toutes les 10 secondes
  );

  // Écouter les messages du serveur
  channel.stream.listen(
    (message) {
      print('Message reçu : $message');
    },
    onDone: () {
      print('Connexion terminée');
    },
    onError: (error) {
      print('Erreur : $error');
    },
  );

Also I found out how backend could send pings himself. I will ask backend to implement ping and experiment with it! So backend work will be needed on this and hopefully we could get something a bit less CPU intensive.

CF linagora/james-project#5367

---

Search a folder (bonus)

When I click onto folder search icon, TMail re-request the full list of folders...

Why no rather use the folder cache?

---

Open the setting page

When I open the setting page (just open without going to the vacation tab) it does VacationResponse/get + VacationResponce/get twice!

I think we could query it only once, and when opening the vacation tab!

[hoangdat]

Hi,

Front-end team appreciate about this kind of detail feedback. The dig deep in the performance of JMAP can not come from only us. The look from back-end are so useful. One more time, we are very appreciated.

Moreover, something was implemented from the beginning, and now, new things were added, some things were changed, it's time to refactor.

We are cross-platform project, so, we should take deep in all aspects to have the good solution for all platforms. The priority should also base on the critical, effort and so on....

[hoangdat]

• Open Folder #3332
• Changing flag (with web socket) #3334
• Moving an email (absolutly critical) #3335
• Websocket PING (important) #3336
• Open the setting page (Vacation method was call twice) #3337
• Page Load (call one more Mailbox/query for spam banner) #3333
• Search a folder (bonus) #3338