Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Matus 24. 09. 2018, 19:11:00
-
Ahoj,
zacinam s programovanim a rozhodol som sa nakodit chattovaciu aplikaciu (pride mi ze sa na tom da poriadne a dost sa toho naucit). Mam vsak otazku ohladom websocketov ktore by som rad pouzil pre realtime komunikaciu. Aky je best practice co sa tyka websocket pre takyto styl aplikacie? Ked sa vytvori spojenie, tak je mozne spravi prijmat zo servera ale aj odosielat bez vytvarania dalsich spojeni so serverom. Co vsak ak aplikacia nebude sluzit len na chattovanie a postupne si pridam dalsie featury, jedna z najrealnejsich moze byt napriklad get na historiu chatu, podobne ako messenger. Alebo proste get na uzivatelov profil, aby som si mohol precitat info o tom s kym pisem?
Malo by sa to spravit vsetko cez jeden kanal, alebo ten jeden kanal pouzit len pre jeden ucel, ako napr prijmanie sprav v realnom case, a odosielanie sprav, a ostatne spominane veci riesit pomocou restu?
Na to odosielanie sprav sa pytam zvlast preto, ze rad by som zobrazil aj upozornenie uzivatelovi, ak sa spravu nepodarilo odoslat, povedzme dostal by som 4xx alebo 5xx, tak sa podla toho viem zariadit (mozno to ide aj vo websocketoch to este neviem, len s tou technologiou zacinam, ak ano kludne ma opravte :). Ako hlavny framework som si vybral Spring, kedze s nim uz mam nejake skusenosti. Dakujem.
-
V rámci vzdělávání bych doporučil udělat tu chatovací mini aplikaci v obou variantách - RESTem i Websocketem. Pro pochopení je nejlepší si to ze začátku víc nakódovat sám a teprve pak používat frameworky. Jinak hrozí, že nebudete vůbec tušit, jak framework funguje, což se časem nezřídka vymstí. Začal bych něčím hodně přímočarým, na server něco jako sparkjava a na klienta jquery. Pak bych šel o level výš a použil už nějaké zastřešující řešení. React,
Pokud budete mít vytvořený websocket, můžete přes něj tlačit vše, udělat si nějaký message bus a ten pak na serveru i klientovi obsluhovat. Ale pozor na to, že websocket spojení může zaniknout a že pak budete muset řešit přeposlání nebo stornování zpráv při výpadku.
-
V skratke, websocket je nieco ako normalny socket, len sa to honosne nazyva, cize mas "otvorenu" linku ,typicky, obojsmernu.
Pri RESTe (normalny HTTP GET/POST) nevies naviazat komunikaciu obojsmerne (pozeraj sa z pohladu chcem poslat data nejakym smerom), server vie odpovedat iba na poziadavku klienta.
Niekolko vyhod:
Server nemusi pracne inicializovat HTTP spojenia pri REST spojeni (nejaka poziadavka), co setri cas aj systemove prostriedky.
Websockety ti umoznuju normalne programovacie paradigma ak mas viacuzivatelsku aplikaciu.
Cize, mozes si to predstavit takto, mas komunikator medzi 3 uzivatelmi. 1 posle text serveru, ako server moze synchronizovat data s dalsimi 2 klientami?
Jednoducho nijako, potrebujes robit nejake oddrby. Napriklad v klientskej applikacii to mas ako while(true){ spytaj_sa_servera_na_novy_text();}
Hlavna nevyhoda websocketov:
Musis sa starat o spojenie.
Inak REST je urcita paradigma pri navrhovani aplikacii, kazdopadne tiez som to pouzil v texte.
-
Fyi
https://www.baeldung.com/websockets-spring
-
Ospravedlnujem sa ak to vyznie drzo, ale mam pocit ze sa mi snazite vysvetlit rozdiel medzi websocketmi a restom. To ako tak ovladam, a nepytal som sa na to. Pytal som sa na moj usecase ktory chcem dosiahnut, a ktory z dvoch variant je lepsie pouzit. Veci ktore tu padli som si uz cital, viem ze cez websocket mozem posielat aj prijmat spravy .. preto som sa pytal ci je to vhodne pouzit na vsetok prenos dat medzi klientom a serverom, alebo len napr. pre realtime komunikaciu ako posielanie sprav, a ostatne veci ako nacitavanie historie chatu, alebo info o uzivatelovi uz cez rest.
-
nepouživej websocket pro věci, kde nemusíš, idealně jen pro ten chat, na ostatni ajax
-
Přes WebSocket protlačíš i komunikaci typu požadavek/odpověď, je to prostě obecnější (posílání zpráv).
V některých frameworcích (Vaadin) se normálně používá REST, ale když někde použiješ "push" ze serveru a tím si do aplikace "zavlečeš" WebSockety, tak celý framework přepne na ně a i to, co jelo dříve přes REST se najednou posílá přes WebSockety.
Na tvém místě bych si zkusil implementovat obě varianty, resp. začal bych tou čistě websocketovou -- abys zjistil, kolik ti to dá práce implementovat požadavek/odpověď přes WebSockety (jak na straně klienta, tak serveru).
A pak musíš ošetřit takové věci jako rozpadající se spojení -- aby nedocházelo k tomu, že jen přestanou chodit zprávy a aplikace se o tom nedozví (zatímco u požadavku/odpovědi by sis všiml, že došlo k chybě).
-
Franta <xkucf03/>
Ondrej Nemecek
Napisat si obe verzie znie ako fajn napad a asi ho aj skusim, kazdopadne z hladiska navrhu je lepsia ktora verzia? pouzit WS na aj aj, alebo ako spominal Franta, tam kde nemusim nepouzivat?
-
Franta <xkucf03/>
Ondrej Nemecek
Napisat si obe verzie znie ako fajn napad a asi ho aj skusim, kazdopadne z hladiska navrhu je lepsia ktora verzia? pouzit WS na aj aj, alebo ako spominal Franta, tam kde nemusim nepouzivat?
-
Franta <xkucf03/>
Ondrej Nemecek
Napisat si obe verzie znie ako fajn napad a asi ho aj skusim, kazdopadne z hladiska navrhu je lepsia ktora verzia? pouzit WS na aj aj, alebo ako spominal Franta, tam kde nemusim nepouzivat?
Vo vseobecnosti, websocket pouzi iba tam kde musis. Ale zavisi to od aplikacie. Ak mas APP, WEB.. ktora je pri vypadku WS nepouzitelna, posielaj si cez WS hoci aj html kod s obrazkami. Ak je to web ktory ma kopec dalsich funkcii, ktore vedia fungovat aj pri vypadku WS, tak WS pouzi iba tam, kde to naozaj treba, alebo tam, kde potrebujes mat v APP data v realnom case.
Inac pri WS som si riadne zanadaval.... Potreboval som na localhoste pri vyvoji vyskusat WSS (sifrovany WS), lebo na HTTPS funguje iba WSS. Tym padom aj web server na localhoste musel byt https a este mi to pindalo ked som sa s WSS isiel pripajat na inu domenu ako bol HTTPS web server... Nesifrovane WS v kombinacii s HTTP fungovalo pekne na "prvu supu", vela stastia... :D
-
Taky teď budu dělat něco podobného.
Prvně udělám aplikaci funkční jen pomocí REST.
Druhý stupeň budou eventy přes WebSocket, kdy se nová data budou posílat ze serveru na klienta.
Třetí stupeň bude i příjmat requesty přes WebSocket.
Jinak mě zajímají další odpovědi pro toto vlákno, s WebSocketem budu dělat poprvé, takže snad tu něco pochytím.
Jazyk: Go
-
Jsem pro použití RESTu tam, kde máme požadavek/odpověď:
1. REST je na to dělaný, u WS si to musíte implementovat. Proč implementovat něco, co mohu mít „zadarmo“?
2. HTTP má několik mechanismů pro cacheování, které můžete využít. Třeba u historie se nabízí If-Modified-Since. Máte připravené hotové mechanismy i jejich implementaci.
Udělat to přes WebSockety – pro edukativní účely klidně, můžete třeba zkusit implementovat odesílání obrázku – a pak řešit, jak velkým obrázkem na pomalé lince nezablokovat ostatní věci. Do produkce by ale musel být nějaký dostatečně silný speciální důvod to udělat takto.
-
V některých frameworcích (Vaadin) se normálně používá REST, ale když někde použiješ "push" ze serveru a tím si do aplikace "zavlečeš" WebSockety, tak celý framework přepne na ně a i to, co jelo dříve přes REST se najednou posílá přes WebSockety.
Proč to tak dělá?
-
Použijte gunDB.
-
V rámci vzdělávání bych doporučil udělat tu chatovací mini aplikaci v obou variantách - RESTem i Websocketem. Pro pochopení je nejlepší si to ze začátku víc nakódovat sám a teprve pak používat frameworky. Jinak hrozí, že nebudete vůbec tušit, jak framework funguje, což se časem nezřídka vymstí. Začal bych něčím hodně přímočarým, na server něco jako sparkjava a na klienta jquery. Pak bych šel o level výš a použil už nějaké zastřešující řešení. React,
Pokud budete mít vytvořený websocket, můžete přes něj tlačit vše, udělat si nějaký message bus a ten pak na serveru i klientovi obsluhovat. Ale pozor na to, že websocket spojení může zaniknout a že pak budete muset řešit přeposlání nebo stornování zpráv při výpadku.
Mam pocit, ze cela otazka je postavena zle. Nevidim zmysel vo vybere ci pouzit websocket alebo REST pri programovani webchatu. Pouzijem oboje. Vie sa to dobre doplnat.
-
Kdyz sem delal podobnou srandu proste sem si tu funkcionalitu obalil jak restem tak websoketama. na webu sem preferoval websokety a pokud nebyli tak to jelo restem.
-
Pouzij rozum. Neni zadna jedina spravna cesta. Kazde ma sve pro a proti, na zaklade toho ceho chces dosahnout si ty pro a proti porovnej a zvol si reseni, ktere ti prijde vhodnejsi. A doporucuju ti pouzivat cisty javascript, nejen z edukativnich duvodu. To ti i nejlepe umozni si porovnat pro a proti. Osobne bych websocket pouzil principialne jen tam, kde komunikaci s klientem zahajuje server.