Příspěvky

46

Vývoj / Re:Synchronizacia real-time dat, s datami z RESTu

« kdy: 22. 05. 2020, 14:01:24 »

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

47

Vývoj / Re:Synchronizacia real-time dat, s datami z RESTu

« kdy: 21. 05. 2020, 22:48:59 »

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.

48

Vývoj / Synchronizacia real-time dat, s datami z RESTu

« kdy: 21. 05. 2020, 21:21:19 »

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.

49

Studium a uplatnění / Re:Nástupní mzda pro absolventa

« kdy: 21. 05. 2020, 21:05:37 »

Kamarád má v Brně SW firmu a kvalitním absolventům dává po zkušebce okolo 100 tisíc. Důraz je na “kvalitní”, což zahrnuje perfektní znalost C++ i soft skills.

Mozem vediet nazov firmy? Tolko totiz niekde neberu ani seniori (na HPP).

50

Studium a uplatnění / Re:Studium IT na vysoké, která je nejlepší.

« kdy: 21. 05. 2020, 21:03:59 »

Zalezi co od studia ocakavas a comu sa chces neskor venovat.
Chces co najkvalitnejsie mozne vzdelanie a smer si vybrat neskor? Volil by som urcite MFF, popripade CVUT ak chces viac technickejsi smer.

Ak chces vseobecny prehlad, a rozvijat sa vo volnom case v oblasti ktora ta bavi, alebo mat dostatok casu na pracu, cokolvek ine.

Sam nemam VS ktora je povazovana za "elitnu" ako napr. MFF, a o plate ktory mam ako vyvojar sa mi popravde ani nesnivalo. Takze z tohto hladiska na skole asi nezalezi, dolezite je aby ta bavilo to co budes studovat / robit. GL.

51

Vývoj / Re:Steamovanie eventov konkretnym uzivatelom pomocou SSE a AMQP v Springu

« kdy: 11. 05. 2020, 11:03:13 »

Strucne vysvetlenie: Ked klient pristupi na url /stream-sse-mvc, tak sa zavola metodka, ktora ulozi SseEmitter (objekt umoznujuci posielat klientovi spravy) v sluzbe BindingMedziTechnologiami do mapy. Nasledne, ked z amqp handleru chcete nieco poslat, pouzijete tu istu sluzbu, ktora z mapy vyberie emitter a posle spravu.

Co chyba, je hendling chýb, vymazavanie klientov z mapy po odhlaseni a podobne "drobnosti".

Hadam nastrel pomoze.

Podobny koncept ma tiez napadol, ale ako by sa riesilo to ak by sa dana aplikacia naskalovala? Alebo ak by uzivatel otvoril aplikaciu na dalsej karte?

52

Vývoj / Steamovanie eventov konkretnym uzivatelom pomocou SSE a AMQP v Springu

« kdy: 10. 05. 2020, 13:28:50 »

Ahojte, mam rabitovy listenery ktore odchytavaju rozne typy eventov, nieco take:

Kód: [Vybrat]

@RabbitHandler
public void processEvent(NewMessageEvent content) {
     // publish to specific user
}

@RabbitHandler
public void processEvent(NewGroupeventCreated content) {
     // publish to specific user
}

Moja predstava by bola taka, ze uzivatel prevola SSE controller, a uvedene listenery mu budu apendovat relevantne eventy. Viete ma prosim trosku nasmerovat, ako na to, a ci je vobec mozne pomocou SSE streamovat specificke eventy konkretnym uzivatelom? Dakujem.

53

Vývoj / Re:Microservice architektura pre real-time aplikaciu

« kdy: 02. 05. 2020, 23:07:50 »

Konkretni priklad: neni "chat-service, ktera zpravu ulozi do DB", je service "db writer", ktera zpravy z Kafky cte a zapisuje do DB, nic jineho nedela. Jina service muze treba zpravy cist a routovat ke spravnemu uzivateli.

Nebudu toto az privelmi male mikrosluzby? Cital som nejaky blog o navrhu mikrosluzieb, a kazda ms by mala riesit konkretny typ uloh (comu odpoveda tvoj navrh), ale zaroven by kazda z nich mala mat aj svoju DB, a v pripade, ze jedna sluzba nemoze fungovat bez druhej, nejedna sa o dobry navrh.

A toto mi pride ako presne tento pripad, pretoze ak writer zapisuje do svojej DB, tak reader nemoze nic precitat a posielat bez toho aby sa neustale dopytaval na data od writera. Cize by som to skor videl ako jednu sluzbu.

54

Vývoj / Re:Microservice architektura pre real-time aplikaciu

« kdy: 02. 05. 2020, 20:33:43 »

Ak ano, tak stale sa neviem uplne stotoznit s tym, preco je zly pristup spravu klasicky ulozit do Db, a nasledne propagovat brokerom dalej. Pride mi to ako zbytocny krok.

Ono zalezi na tom jak si jednotlive services definujes. Co bude jejich zodpovednost. Pokud se o historii chatu bude starat ta sama service, co prijala novou zpravu, tak je sumak, co se stane prvni. Jestli nejdrive ulozis do database nebo posles event do brokera. Jestli se o historii bude starat samostatna service, tak ani jinou moznost, nez to nejdrive poslat na brokera nemas. Jednotlive services by si nemeli sahat vzajemne na data.

Presne ako hovoris, ak by sa o historiu a ukladanie starala ina sluzba, vedel by som si to predstavit ze konzumuje spravy z kafky a uklada. Ale ak bude dana mikrosluzba obstaravat danu domenu, cize chat, nedava mi velmi zmysel posielat ju do Kafku aby som si ju potom aj v tej istej sluzbe odchytil.

55

Vývoj / Re:Microservice architektura pre real-time aplikaciu

« kdy: 02. 05. 2020, 19:35:45 »

2) Kde v tomto modeli by si riesil ukladanie dat do db aby bolo mozne prehliadanie historie?

Stejně, jak to psal nějaký kolega výš: jeden z Kafka clientů je zapisovač do DB.

Moze byt microservice ktora posiela spravu do kafky zaroven klientom ktory spravu precita a ulozi? Snazim sa si to predstavit na priklade ako som spominal (napr. chat-microservice).

1. Pride POSTom nova sprava do mikrosluzby chat-service
2. Ihned sa sprava preposle do kafky na spracovanie.
3. Az pride sprava v kafka na rad, precita si ju chat-service, a ulozi do DB. Po ulozeni sa posle do kafky sprava v novom evente urcenom pre notification-service, ktora posle websocketom spravu na FE.

Ten medzikrok mi dava zmysel v tom, ze prijemcovi by mala ist iba ulozena sprava, a nestalo sa to, ze nahodou mu bola dorucena sprava, ktora pri ulozeni zlyhala, takze az si refreshne prehliadac, tak uz ju tam neuvidi. Je to takto ok?

Ak ano, tak stale sa neviem uplne stotoznit s tym, preco je zly pristup spravu klasicky ulozit do Db, a nasledne propagovat brokerom dalej. Pride mi to ako zbytocny krok.

56

Vývoj / Re:Microservice architektura pre real-time aplikaciu

« kdy: 02. 05. 2020, 19:12:18 »

Ke komunikaci s FE použij jenom websockety. Oznámit přes websockety událost a pak data načítat klasicky nedává žádný smysl. Datový kanál už máš, tak ho použij, ne?

dává to smysl, je to bezestavové. Websockety na notifikace, data tahat přes API.

Trosku som sharlockoval a podobny mechanizmus vraj pouziva FB

57

Vývoj / Re:Microservice architektura pre real-time aplikaciu

« kdy: 02. 05. 2020, 19:11:10 »

A jakmile máš data v Kafce, s naprosto dostatečnou* jistotou už o ně nepřijdeš. Čili žádný potvrzování nemusíš řešit, pokud vyloženě nechceš (třeba abys uživateli ukázal ticker "doručeno").

Všechny další komponenty systému budou komunikovat přes Kafku, takže je můžeš beze strachu restartovat jak je libo. Že se nic neztratí, ti už Kafka zabezpečí (pokud ji správně použiješ).

1) Co ak sa restartuje Kafka? Nepride o data ktore definovali komu ma aka sprava ist?

2) Kde v tomto modeli by si riesil ukladanie dat do db aby bolo mozne prehliadanie historie?

Dik

58

Vývoj / Re:Microservice architektura pre real-time aplikaciu

« kdy: 02. 05. 2020, 16:48:03 »

Co poviete na tento model?

Pouzivatel bude POSTom posielat requesty na konkretne mikrosluzby, ci uz to bude chat, poll, alebo cokolvek ine. Budu to jednoduche requesty ktore ulozia data do DB, takze nebude problem na zaklade response status notifikovat uzivatela o tom, ci sprava bola v poriadku prijata. Po ulozeni dat do DB, sa posle event o prijati novych dat, ktory odchyti notifikacna mikrosluzba, na ktoru budu pouzivatelia napojeni cez WS alebo SSE, a posle spravu FE aplikacii. Po tom ako FE obdrzi event ze su k dispozicii nove data, spravi FE klasicky GET.

59

Vývoj / Re:Microservice architektura pre real-time aplikaciu

« kdy: 01. 05. 2020, 23:42:42 »

Já bych to viděl tak, že pokud chcete mít 100% spolehlivost, potřebujete distribuované transakce. A to je samostatné téma.

Pokud nechcete 100% spolehlivost, končíte s tím, že se požadavek předal systému a že máte brokera nastaveného tak, aby nic neztratil.

Dakujem, tak co sa tyka toho tak skusim si to nastudovat, a zatial by som to uzavrel s tym, ze ten flow bude nasledovny:

request uzivatela z FE -> poll-microservice (publisher) -> broker -> notfication service (subscriver) -> FE

A to posielanie notifikacii uzivatelovi na FE, pouzili by ste skor SSE alebo websockety? Ak by som uz mal otvoreny ws kanal, tak by zrejme bolo vhodne posielat cez neho aj spravy z FE smerom na server.

60

Vývoj / Re:Microservice architektura pre real-time aplikaciu

« kdy: 01. 05. 2020, 21:32:17 »

jde o to kolik technologii chces zapojit, jak to mit co nejjednodussi.
zasadni je synchronizacni mechanismus, zda to bude nejaka async fronta, db, cokoliv.
ale pouzij hvezdici at nemas v grafu sluzeb kruhy.

O jednoduchost mi velmi nejde, uz teraz mikrosluzby, broker, a pod. na votovaci system je trosku kanon na vrabca. Ide mi len o to pohrat sa s technologiami a architekturou aka by bola pouzita na realnom vacsom projekte.