Doporučte řešení pro Real Time konverzace One to One uživatelu v rámci aplikace

Oleg

(53 hodnocení)

11. 1. 2017 09:21:20

Ahoj,

premyslim jake reseni zvolit pro real time konverzaci dvou (vzdy pouze dvou) uzivatelu mezi sebou.

Konverzace bude probihat vzdy mezi registrovanymi uzivateli.

WebApp je programovana v Laravel 5.

Muzete mi doporucit nejake rozumne ne moc zatezujici reseni?

Nedovedu odhadnout kolik paralelnich konverzaci zaroven bude probihat... Mozna bude pouze jedna, nebo treba zaroven 5000.

Zpravy mezi uzivateli budou nejakou dobu uchovavane v DB a po case automaticky odstranene.

Premyslel jsem tez o jednoduchem reseni na bazi PHP/AJAX. Ale mozna Vas napadne neco jineho.

Zaroven bych potreboval napric backendem posilat notifikaci o doruceni nove zpravy.

Layout (UI) prikladam nize.

Diky za nazory.

22182

11. 1. 2017 09:21:20

https://webtrh.cz/diskuse/doporucte-reseni-pro-real-time-konverzace-one-to-one-uzivatelu-v-ramci-aplikace/#reply1249375

David Musil

(69 hodnocení)

11. 1. 2017 09:36:26

Ja bych cestou PHP/AJAX klidne sel. Urci se cas, kdy se bude chat refreshovat.

Pro kazdou konverzaci bych videl jeden zaznam v tabulce konverzaci, kde by byly krome jineho IDcka obou uzivatelu. To znamena, i kdyz si zacnou psat znovu po jednom roce (a zpravy uz budou smazane), porad maji jedno IDcko konverzace. Druhou tabulkou by byly samotne zpravy a pomoci ID_konverzace by se odkazovalo na samotnou konverzaci a pres JOIN by se tahaly uz jen zpravy techto dvou uzivatelu.

Ja jsem to resil takhle - nerikam, ze je to nejlepsi reseni.

11. 1. 2017 09:36:26

https://webtrh.cz/diskuse/doporucte-reseni-pro-real-time-konverzace-one-to-one-uzivatelu-v-ramci-aplikace/#reply1249374

unlucky

(16 hodnocení)

11. 1. 2017 09:58:55

spise by me zajimalo, proc by lidi pouzivali vas chat misto tedka dost oblibeny FB.

I ICQ, Yahoo a msn sly kde dnu.

11. 1. 2017 09:58:55

https://webtrh.cz/diskuse/doporucte-reseni-pro-real-time-konverzace-one-to-one-uzivatelu-v-ramci-aplikace/#reply1249373

David Musil

(69 hodnocení)

11. 1. 2017 10:17:13

Napsal unlucky;1352737
spise by me zajimalo, proc by lidi pouzivali vas chat misto tedka dost oblibeny FB.
I ICQ, Yahoo a msn sly kde dnu.

Treba proto, ze tohle je chat v ramci aplikace? :)

Takovych je i dnes spousty.

11. 1. 2017 10:17:13

https://webtrh.cz/diskuse/doporucte-reseni-pro-real-time-konverzace-one-to-one-uzivatelu-v-ramci-aplikace/#reply1249372

node

(5 hodnocení)

11. 1. 2017 10:24:00

Rieseni je vela od websocketov(samostatny server, ale mozes kludne pouzit napriklad reactphp ak nechces menit technologie za nodejs, go, python a pod.), cez Server Sent Events az po polling(ajax).

Vsetko zalezi od zataze. Websockety budu najvykonnejsie ale aj najkomplikovanejsie na implementaciu. Osobne fandim najviac SSE(mozes mat otvorene spojenie kde ti server zasle event ked je nova sprava v DB na co mozes zareagovat ajax requestom).

11. 1. 2017 10:24:00

https://webtrh.cz/diskuse/doporucte-reseni-pro-real-time-konverzace-one-to-one-uzivatelu-v-ramci-aplikace/#reply1249371

Oleg

(53 hodnocení)

11. 1. 2017 11:15:51

Napsal unlucky;1352737
spise by me zajimalo, proc by lidi pouzivali vas chat misto tedka dost oblibeny FB.
I ICQ, Yahoo a msn sly kde dnu.

Neni to chat verejny. Je to v ramci jedne web app. Tj. existuje skupina uzivatelu A a skupina uzivatelu B. Pokud nejaky uzivatel ze skupiny A se chte zeptat na neco u uzivatele ze skupiny B tak mu napise i kdyz je offline. Uzivateli z B se objevi v backnedu (teda jeho administraci) notifikaze, ktera indikuje prijem noveho dotazu. Uzivatel B odpovi uzivateli A i kdyz je treba offline. Tim to hasne. Zadne skupinove konverzace :)

@musil.david mas statistiky jak je tvoje reseni narocne na zpracovani pozadavku a storage pro data? My potrebujeme prave take ziskavat stav doruceni. Teda zda je zprava prectena nebo nikoliv, na zaklade toho jednou denne odeslat transakcni mail (upominku) aby se uzivatel prihlasil a precetl nove zpravy.

---------- Příspěvek doplněn 11.01.2017 v 11:25 ----------

Napsal node;1352745
Rieseni je vela od websocketov(samostatny server, ale mozes kludne pouzit napriklad reactphp ak nechces menit technologie za nodejs, go, python a pod.), cez Server Sent Events az po polling(ajax).
Vsetko zalezi od zataze. Websockety budu najvykonnejsie ale aj najkomplikovanejsie na implementaciu. Osobne fandim najviac SSE(mozes mat otvorene spojenie kde ti server zasle event ked je nova sprava v DB na co mozes zareagovat ajax requestom).

SSE ani websocket nepodporuje IE, coz je hodne limitujici a pravdepodobne AJAX by bylo reseni. Ale nevim...

11. 1. 2017 11:15:51

https://webtrh.cz/diskuse/doporucte-reseni-pro-real-time-konverzace-one-to-one-uzivatelu-v-ramci-aplikace/#reply1249370

node

(5 hodnocení)

11. 1. 2017 11:35:14

Pre SSE v IE je polyfil. Ale ano, Ajax je jediny bezproblemovy, preto ho stale pouzivaju aj giganti ako Google vo svojich sluzbach.

11. 1. 2017 11:35:14

https://webtrh.cz/diskuse/doporucte-reseni-pro-real-time-konverzace-one-to-one-uzivatelu-v-ramci-aplikace/#reply1249369

Oleg

(53 hodnocení)

11. 1. 2017 11:45:26

Napsal node;1352776
Pre SSE v IE je polyfil. Ale ano, Ajax je jediny bezproblemovy, preto ho stale pouzivaju aj giganti ako Google vo svojich sluzbach.

No prave ja potrebuji ne moc narocne reseni a zaroven funkcni :) Ale nevim, ktere aby to nepolozilo server :)

11. 1. 2017 11:45:26

https://webtrh.cz/diskuse/doporucte-reseni-pro-real-time-konverzace-one-to-one-uzivatelu-v-ramci-aplikace/#reply1249368

node

(5 hodnocení)

11. 1. 2017 12:08:40

Tak ako som pisal, ja som fanda SSE. Otvoris si tak jedno spojenie a mozes tak pouzivat eventy ako "pise..." a pod a bud si tak aj rovno nastreamujes spravy alebo mozes reagovat na event a spravit poll.

Pri ajaxovom rieseni ide o to ze sice nemas neustale otvorene spojenie ale za to robis polling kazdu, napriklad, 1 sekundu. Cize ked si to tak vezmes tak pri 5000 chatoch(1-to-1) to mas so SSE 10000 neustale otvorenych spojeni + 1 spojenie ked pride/odide nova sprava(pri pollingu, ak to neimplementujes vsetko do jedneho streamu). Cize by si mal jeden in-stream a jeden post request pre odoslanie spravy. Co mas 10000x spojenie + 10000 jendorazovych spojeni pre spravy pri dvoch ludoch(pri odoslani az).

Pri ajaxovom pollingu to mas, pri jednosekundovom pollingu, 10000 requestov kazdu sekundu. Prakticky to stale znamena 10 000 dopytov na db v jeden cas ale nemusis stracat cas nadvezovnaim spojenia 10 000 za sekundu ak by si pouzill sse.

Prakticky je rozdiel v tom ze polling bude pomalsi(nadviazanie spojenia) a pri SSE mas spusteny proces pre kazdy request stale, kdezto pri pollingu sa process zatvori.

Ale on zase pride TomasX a hned ti vysvetli ako sa to ma spravne robit :D

---------- Příspěvek doplněn 11.01.2017 v 13:55 ----------

Toto je presne pre teba https://speakerdeck.com/clue/t3dd16-pushing-the-limits-with-react-php

11. 1. 2017 12:08:40

https://webtrh.cz/diskuse/doporucte-reseni-pro-real-time-konverzace-one-to-one-uzivatelu-v-ramci-aplikace/#reply1249367

skorozacatecnik

12. 11. 2017 14:53:57

Napsal Oleg;1352729
Ahoj,
premyslim jake reseni zvolit pro real time konverzaci dvou (vzdy pouze dvou) uzivatelu mezi sebou.

Ahoj. Je to nejaky mesic zpet, ale chci se zeptat, jak to dopadlo s chatem, uz bezi a na cem nakonec? Jak je to se zatezi? A na cem to zije, co to spolkne za vykon atp.?

Nejaky cas resim aplikace na WebSocketech, tak koukam po zkusenostech ostatnich a moznostech jinych technologii pro real-time komunikaci aplikaci. Zatim websockety muzu jen doporucit (az na komplikovanou implementaci).

12. 11. 2017 14:53:57

https://webtrh.cz/diskuse/doporucte-reseni-pro-real-time-konverzace-one-to-one-uzivatelu-v-ramci-aplikace/#reply1249366

Pro odpověď se přihlašte.

Přihlásit