Client/Server Architektur realisieren - Ideen

[Sir Rufo]

Egal ob Chat oder irgendwelche sonstigen Benachrichtigungen, dafür eine extra Service-Anwendung zu bauen und die Komplexität zu erhöhen halte ich für unklug.

Die REST-API weiß, ob eine bestimmte Aktion eine Benachrichtigung erfordert. Wenn, dann trägt diese das in die entsprechenden MessageQueues ein. Diese MessageQueues werden vom Client selber überwacht/abgefragt (Long Polling).

Ob diese Benachrichtigung nun eine Chat-Nachricht oder eine Änderung an dem Datensatz X betrifft spielt doch keine Geige. Das muss der Nachrichteninhalt hergeben.

Was du mit dem Änderungszeitpunkt anfangen möchtest ist mir auch noch nicht klar.

In einem System (speziell einem asynchronen) sollte jede Änderung (Nachricht vom Client an die API) den Zeitpunkt des Auftretens (ocurred) beinhalten. Die API fügt dann noch den Zeitstempel ein, wann das empfangen wurde (received) und trägt die Information ein.

(Muss ich erwähnen, dass die Zeitbasis immer UTC-bezogen sein sollte?)

Jetzt kommen wir zum eigentlichen Kern:

Gibt es in der API schon einen Eintrag, mit einem jüngeren ocurred, dann hat sich der Datensatz nicht verändert - die Historie hat sich sehr wohl verändert - und zieht somit keine weitere Aktionen der anderen Clients nach sich, es sei denn, die schauen sich die Historie an.