Synchronizacia real-time dat, s datami z RESTu

[schwantner.peter]

Ahojte, vie mi niekto poradit s najlepsim moznym riesenim pre dany problem?

Jedna sa spravu eventov, pouzivatel sa prihlasi do aplikacie, a aplikacia si okamzite stiahne inicializacnu davku -> N poslednych eventov. Zaroven sa aplikacia po prihlaseni pripoji websocketom na server, kde zacne konzumovat nove eventy v realnom case, popripade odosielat eventy daneho pouzivatela.

Pri odoslani eventu na server, sa event zapise do DB a posle cez queue a websocket dalsim pouzivatelom. Eventy mozu pribudat celkom rychlo (cca 1/s), a tak moze nastat edge case, kedy pouzivatel A odosle pouzivatelovi B event. Tesne na to sa pouzivatel B prihlasi do aplikacie, a aplikacia posle GET pre inicializacnu davku, a napoji sa na websocket. Novy event mu teda pride v inicializacnej davke, a precita si ju aj websocketom, cize je potrebne dodatocne filtrovanie.

Viete mi prosim poradit ako by ste riesili synchronizaciu starsich dat, a dat ktore prichadzaju v realnom case? Dakujem.

[Reklama]

[schwantner.peter]

Celkom jednoduche ktore ma napadlo je handlovat websocketom spravy o tom, ze su nove eventy k dispozicii, a nechat na klientovi aby si RESTom stiahol eventy ktore potrebuje, na zaklade posledneho. To by ale znamenalo strasne vela GET requestov co neni idealka ak uz existuje WS.

[SB]

Bez ohledu na to, zda to již neřeší nějaká knihovna/framework: Ty události nemají časové razítko či jedinečné označení, podle kterých by bylo možno si vyžádat podmnožinu či rozlišit duplicity?

[Filip Jirsák]

Tohle už má hotové třeba Firebase Cloud Firestore nebo PouchDB.

[schwantner.peter]

Bez ohledu na to, zda to již neřeší nějaká knihovna/framework: Ty události nemají časové razítko či jedinečné označení, podle kterých by bylo možno si vyžádat podmnožinu či rozlišit duplicity?

To s razitkom je dobry point, napadlo ma nieco taketo, skuste povedat co si o tom myslite:

1. aplikacia sa pripoji websocketom na kanal kde pocuva na eventy
2. ako odpoved mu pride presny timestamp T, kedy bolo spojenie naviazane, teda od kedy aplikacia pocuva na nove eventy
3. aplikacia si GETom vyziada poslednych N eventov, ktore maju timestamp mensi ako T

[Reklama]

[M_D]

A nešlo by to řešit na straně toho websocket serveru? Jak se na něj naváže naváže nové WS spojení, tak pošle do něj těch X posledních eventů a pak už posílá co nového přibývá. Tím pádem apliace v prohlížeči nemusí paralelně si sahat zvlášť pro start dávku a druhým otvírat WS pro novinky. Otevře jen WS a v nm dostane vše už v správné řadě i s počíteční historií.

[schwantner.peter]

A nešlo by to řešit na straně toho websocket serveru? Jak se na něj naváže naváže nové WS spojení, tak pošle do něj těch X posledních eventů a pak už posílá co nového přibývá. Tím pádem apliace v prohlížeči nemusí paralelně si sahat zvlášť pro start dávku a druhým otvírat WS pro novinky. Otevře jen WS a v nm dostane vše už v správné řadě i s počíteční historií.

Ide o to, ze pouzivatel si moze nacitat a prehliadat aj starsie eventy ako je tych inicializacnych N, takze aplikacia si bude musiet dotahovat aj starsie data, a teda by bolo mozne vyuzit rovnaky endpoint pre tieto data.

[Standa Blábol]

Je nejaky duvod, aby prvni davka sla restem a zbytek websocket?
Nemuze to jit pres websocket primo?

Jinak presne na tyto druhy ukolu je Apache/Kafka, udelej si pred to websocket wrapper a hotovo.

Navic Kafka slouzi rovnou jako databaze, zapis do externi nemusi byt potrebny.

[M_D]

Tak ono bude i záležet o to, jakou technologií to na straně serveru bude řešeno. Může být to vše v rámci toho WS spojení, můžete mít vedle sebe WS a klasické GET.
Pokud bych tam měl třeba mosquitto MQTT, který v základu umí, že při navázání spojení pošle hned poslední archivovanou zprávu, tak si otevřu WS spojení, přijde mi hned poslední zpráva a pokud z ní odvodím, pro co si sáhnu přes GET do archívu, tak je to to, co popisujete ve svém návrhu.
Pokud budu mít použitu třeba Kafku, kde si jde snadno sáhnout pro X posledních zpráv, tak v rámci navázání WS spojení pošlu i posledních X zpráv a GET API budu mít bokem pro interaktivní listování archivem dle toho, jak uživatle kliká.
Možností je vždy víc...

[Standa Blábol]

Apropos, klient ma byt clovek sedici u webu?

Tam bych to s realtimovosti nevidel nijak zhave.

Pokud to ma byt chat, tady mas primo hotovej exampl, staci opajcovat
https://spring.io/guides/gs/messaging-stomp-websocket/

Pokud ma byt konzument stroj, pak doporucuju napojite se naprimo na Apache/Kafka, pripadne NATS (ale to je jenom hloupy message broker, neumi to co Kafka)

[Standa Blábol]

Apropos, klient ma byt clovek sedici u webu?

Tam bych to s realtimovosti nevidel nijak zhave.

Pokud to ma byt chat, tady mas primo hotovej exampl, staci opajcovat
https://spring.io/guides/gs/messaging-stomp-websocket/

Pokud ma byt konzument stroj, pak doporucuju napojite se naprimo na Apache/Kafka, pripadne NATS (ale to je jenom hloupy message broker, neumi to co Kafka)

Chybka, odkaz mel byt https://www.callicoder.com/spring-boot-websocket-chat-example/

[schwantner.peter]

Jinak presne na tyto druhy ukolu je Apache/Kafka, udelej si pred to websocket wrapper a hotovo.

Navic Kafka slouzi rovnou jako databaze, zapis do externi nemusi byt potrebny.

S tou Kafkou to bude asi zlozitejsie, momentalne pouzivame ako broker RabbitMQ.
Prijate eventy ukladame do relacnej DB, ktora je pre nas jedny zdroj "pravdy".

Pokud to ma byt chat, tady mas primo hotovej exampl, staci opajcovat
https://www.callicoder.com/spring-boot-websocket-chat-example/

Ako koncept WS asi ok, ale neriesi tam historiu a uvodny fetch dat.