Zdravim ,

začal som sa tak hrat zo socketmi zatial len nejaké js mini aplikacie (chat ) ale zaujímalo by ma ako to rozbehať s phpckom ,
nasiel som elephant.io to bolo na prvom mieste ked som dal do googla socket.io + php , mašiel som aj nejake ine knižnice alebo čo to je ale posledný commit na githube napr 2roky starý . ten elephant mal 4 mesiace tak zatial ma najviac laka to ale chcem sa opýtať ak tu stým niekto robí že čo používa a čo je najlepšie a tak.

Najvacsi uspech som mal s PHP <-> Redis <-> NodeJS <-> socket.io kombinaciou. To v pripade, ze ti ide o nieco custom. Inak odporucam Pusher.

záleží čo má tá tvoja aplikácia robiť, ale s tým Aidenovým návrhom celkom súhlasím. Možno by som iba Redis nahradil za RabbitMQ alebo nejaký iný frontovač, príde mi to vhodnejšie na výmenník dát lebo sa lepšie vysporiadaš s nárazmi v špičke

Niečo som si prečital o tom Redise ale nejak tomu nerozumiem.
Konkretne ked niečo chcem poslat na node.js server načo to potrebujem ukladať niekde do pamete ? Alebo aj na disk napr nejake spravy ktore z chatu ktore proste nikde nechcem uložit ale len odoslať všetkym pripojením klientom k tomu node serveru ?
Aby som spustil redis potrebujem ešte aj nato nejaky redis server ? Teda budem mat spusteny node.js , redis a este aj apache server ? Napr toto vsetko nejakom virtualnom servery.

Ked sa zaplni pamet tak čo potom ? (Chapem že sa to asi tak lahko nezaplni alebo ako ste písali že ked to už je nejake večsia appka tak použit niečo ine )



Nejak mi to proste nejde do hlavy prečo to takto je Budem rad ak mi to tu niekto aspon nejako objasni

Ešte sa chcem opýtať čo si myslite o Vue.js

Prakticky nie je rozumny sposob, ako pouzit websockets v PHP (Ratchet a podobni sa snazia, ale...), preto sa pouziva napr. Node. Avsak PHP potrebuje komunikovat s Node castou a hoci to mozes vyriesit nejakym API na Node strane (co prinasa nejake starosti a obmedzenia), krajsie je pouzitie nejakeho PubSub/message broker elementu medzi nimi. Napr. spominany Redis alebo RabbitMQ.

Ale inak ano, bezal by ti Node, Redis (alebo nieco ine) a aj Nginx (Apache by som uz nechal na pokoji ) na jednom alebo viacerych strojoch podla potreby. Ked sa zaplni pamat, tak by si o tom uz mal nejaky cas vediet a mat naplanovany scaling HW alebo dropletu.

Co sa tyka Vue, tak po skusenostiach s Backbonom, Angularom, Emberom a Reactom prisiel ako prijemne prekvapenie so sirokym vyuzitim. Hodi sa na upratanie JS, ktory sa casto pisal s jQuery do pseudo-OOP tvaru, ako aj na vytvorenie SPA (uz teraz po poslednych updatoch vue-routera). Evan sa snazi, fixuje issues rychlo, komunikuje na Twitteri, formuje sa komunita aj na Gritteri a Laracasts... Myslim, ze pocas tohto roka sa Vue rozsiri celkom vyrazne. Navyse dokumentacia je tiez pekne napisana.

Aiden napísal: Co sa tyka Vue, tak po skusenostiach s Backbonom, Angularom, Emberom a Reactom prisiel ako prijemne prekvapenie so sirokym vyuzitim. Hodi sa na upratanie JS, ktory sa casto pisal s jQuery do pseudo-OOP tvaru, ako aj na vytvorenie SPA (uz teraz po poslednych updatoch vue-routera). Evan sa snazi, fixuje issues rychlo, komunikuje na Twitteri, formuje sa komunita aj na Gritteri a Laracasts... Myslim, ze pocas tohto roka sa Vue rozsiri celkom vyrazne. Navyse dokumentacia je tiez pekne napisana.

Ja musim

tych Js frameworkov je tak strasne vela, ze to sposobuje rozhodovaciu paralizu:/

Nieco na tom rozhodne bude #VueHYPE

Dufam ze sa ten vue uchytí lebo tiez neviem co si mam vybrat raz skusam to raz to a vzdy sa niekde dozviem o niečom inom tak snad Vue.js budu vsetci chcieť pouzivat ja ho budem vediet a budem ziadany



//autoeditácia príspevku (10 Jan 2016, 2:48)
Takze ked napr chcem mat nejaky web kde bude napr registracia cez php , prihlasovanie atd potom napr ten chat spravit tak ze ked klikne na link napr Chat miestnost tak ta miestnost bude napisana len v js. Teda po kliknuti sa to pripoji na node server.

Je to tak lepšie? Ked píšeš že rozumný spôsob komunikácie php a socketov neexistuje

mnichovcan napísal:Takze ked napr chcem mat nejaky web kde bude napr registracia cez php , prihlasovanie atd potom napr ten chat spravit tak ze ked klikne na link napr Chat miestnost tak ta miestnost bude napisana len v js. Teda po kliknuti sa to pripoji na node server.

Je to tak lepšie? Ked píšeš že rozumný spôsob komunikácie php a socketov neexistuje

Mozno to pojde aj bez toho https://github.com/Flynsarmy/PHPWebSocket-Chat .

Aiden napísal:Nieco na tom rozhodne bude #VueHYPE

Inac aky Fw by si odporucil cloveku, ktory ma skunosti len s Knockout.js, nechce Angular. Prosto rad by som nieco (vyvojarsky) stabilne, a nie komplikovane na zaciatok pre SPA.

Vue alebo React.js pravdepodobne, Vue je uz vo verzii 1.0, a pravdepodobne bude stale popularnejsi a ziadanejsi. Vue je dost podobny angularu (kedze typek pracoval v google na angulari), ale ma vela veci ktore angularu chybaju, alebo su na nom celkom awkward. Na SPA je Vue viac ako dostacujuci.

@PHPWebSocket - Osobne by som sa vyhol knizniciam s 3 commitmi, bez testov a 4 roky nedotknutym... ale fungovat to moze

React je skvely, ale nie som si isty, ci zapadada do "nie komplikovane". Je super, ak dokazes prekusnut JSX (co mne osobne vzdy trochu vadilo) a zacnes pouzivat Flux architekturu.
Mozno by pripadal do uvahy Ember. Presli celkom vyraznymi zmenami s Ember Data a Ember Cli trochu davnejsie, ale vyzera to, ze uz nasli svoju cestu. Kazdopadne treba pocitat s tym, ze celkom silno tlacia "convention over configuration", co ti na jednej strane umozni zbuchat relativne jednoduchu appku velmi rychlo, ale ked chces nieco viac custom, tak sa to uz v nicom nelisi od inych FW. Kazdopane heavy RESTful appky sa v nom robia velmi dobre.

Pokial ti vsak nevadi stale celkom aktivny development (hoci je dostupny stable production ready branch), tak s Vue by si bol tiez urcite spokojny. Ma vyrazne jednoduhsiu syntax, vsetko je o komponentoch (ktore su urobene dobre v porovnani s Angularom 1), je velmi rychly, ma nazorne vyriesene events. Mne sa paci hned od zaciatku a pouzivam ho vsade, kde by som predtym pouzil Angular alebo React Skus prebehnut toto, je to tak na hodinku a je to skvely resource na zaciatok.

Vue zatial nechcam tak, nie je to z funkcionality, ale hladam nieco odlezanjsie.

Inak ako spolu suvisi Flux a React.js?

Aiden: vies ich porovnat s Backbone ? Na nom sa mi paci MVVM model (ako v knockout.js alebo WPF).
A JSX, neviem viac sa mi paci mat pohlady v <secript type="text/template">.... mozno len sila zvyku.

Flux nie je priamo potrebny pre pracu s Reactom, ale je to skor convenience... je to viacmenej store pattern obaleny eventami. Kratky overview napr. tu.
V principe ak mas napriklad blog page component, ktory obsahuje blog list component, ktory ma blog entry components, tak nechces posielat http request z kazdeho blog entry componentu na ziskanie potrebnych dat. Standardne posles GET @ /posts z blog list componentu a do blog entry componentov poskytnes len relevantne data pre dany entry. Co vsak urobit, ked chces zmenit napr. kategoriu pre nejaky blog entry? Urobis to vo vnutri blog entry componentu (PUT @ posts/:id), ale nasledne mozno chces refreshnut blog list, lebo to napriklad malo nejake nasledky (zmena struktury listu, alebo aj vynechanie entry v danom liste). Samozrejme to vzdy vies vyriesit nejakou formou komunikacie s blog entry -> blog list, ale Flux poskytuje jednoduchy sposob jednosmerneho toku dat, kedy ti staci dispatchnut event, ktory je nasledne propagovany a odchyteny tam, kde to je potrebne (v tomto pripade v blog liste, kde vyvola refresh listu). Dalo by sa povedat, ze to zjednodusuje pracu s datami a zabranuje to chaotickej komunikacii medzi komponentami pri vacsich aplikaciach.

Pokial chces nieco odlezane (a open-source), tak realne mas na vyber z Angularu, Reactu, Emberu a KO.
- Knockout je jednak MVC a co sa tyka rychlosti, tak je skor na pomalsej strane z tejto skupiny
- Angularu 1 by som sa uz teraz vyhol... ked sa mozno o rok, dva zabehne Angular 2, bude mat opat zmysel, ale pokial chces A1 pouzivat na komponentovy layout, tak budes nadavat
- Ember je tiez MVC a dokazes v nom rychlo napisat appku, pokial nepotrebujes urobit nieco krkolomne, vtedy zacnes viac extendovat, ako je prijemne. Ember je velmi opinionated. Na templating pouziva Handlebars, co sa mne vzdy velmi pacilo.
- React vie byt asi najviac MVVM, aj ked je to skor iba V(M) v zaklade, ak vsak prezijes JSX a akceptujes Flux, tak je prijemny na pouzivanie. Miestami sa moze zdat, ze pridavas viac komplexity, ako by si mozno chcel, ale aspon nemusis preliezat mury konvencii, ako v pripade Emberu.

Na aplikacie s vela resourcami, kde nepozadujes velmi fancy fukncionalitu, by som volil Ember a na vsetko ostatne React. Najlepsie ale urobis, ak si urobis nejaky weekendovy projekt v oboch a zistis, co ti viac vyhovuje. Je to naozaj pain vybrat ten spravny a to som teraz nebral do uvahy Mithril, Aureliu, Riot, Polymer alebo Ext JS. Najviac sa mi ale osvedcila jednoduchost v tychto frontendovych FW. Asi aj preto som momentalne na Vue. Pouziva sa lepsie, ako Angular, je rychly, lahko testovatelny, dokazes v nom to, co v Reacte (napr. uz sa pripravuje dokonca aj Vue-Flux) a nezavadzia ti ako Ember

To urrčite nebudem skušat aj ked by to fungovalo

Zaujímalo by ma to či je to ok ako som napísal vyššie alebo je to hlúposť takto robiť aj ked my to zatial fungoval ale je to len mala appka.

Takze ked napr chcem mat nejaky web kde bude napr registracia cez php , prihlasovanie atd potom napr ten chat spravit tak ze ked klikne na link napr Chat miestnost tak ta miestnost bude napisana len v js. Teda po kliknuti sa to pripoji na node server.

Je to tak lepšie? Ked píšeš že rozumný spôsob komunikácie php a socketov neexistuje

Ešte k tym FW takže zatial neovladam žiadny nejak extra ale snažím sa ten Vue nejak dostat do krvi . Nemusím teda pozerať po iných ?
Lebo vždy ked som z nejakym začal zistil som že exituje aj nejaky iný a od toho predchadzajuceho ma to odradilo lebo vždy si poviem že ten novy je lepši a takto to ide dokola a nakoniec neviem ani jeden Ale teraz mam zaplatene na laracasste pristup k všetkym videam a je tam serial k Vue tak sa sustredim nan asi.

Kludne sa sustred na Vue, ak sa ho naucis, bude to fajn. Je lepsie vediet co to o viacerych, aspon aby si mal nejaky zakladny prehlad, ale specializovat sa na jeden urcite nezaskodi.

Okrem toho Laracasts je extremne dobry resource, kde sa takmer urcite z teba stane lepsi dev. Len tak dalej.

Aiden napísal:Flux nie je priamo potrebny pre pracu s Reactom, ale je to skor convenience... je to viacmenej store pattern obaleny eventami. Kratky overview napr. tu.
V principe ak mas napriklad blog page component, ktory obsahuje blog list component, ktory ma blog entry components, tak nechces posielat http request z kazdeho blog entry componentu na ziskanie potrebnych dat. Standardne posles GET @ /posts z blog list componentu a do blog entry componentov poskytnes len relevantne data pre dany entry. Co vsak urobit, ked chces zmenit napr. kategoriu pre nejaky blog entry? Urobis to vo vnutri blog entry componentu (PUT @ posts/:id), ale nasledne mozno chces refreshnut blog list, lebo to napriklad malo nejake nasledky (zmena struktury listu, alebo aj vynechanie entry v danom liste). Samozrejme to vzdy vies vyriesit nejakou formou komunikacie s blog entry -> blog list, ale Flux poskytuje jednoduchy sposob jednosmerneho toku dat, kedy ti staci dispatchnut event, ktory je nasledne propagovany a odchyteny tam, kde to je potrebne (v tomto pripade v blog liste, kde vyvola refresh listu). Dalo by sa povedat, ze to zjednodusuje pracu s datami a zabranuje to chaotickej komunikacii medzi komponentami pri vacsich aplikaciach.

Pokial chces nieco odlezane (a open-source), tak realne mas na vyber z Angularu, Reactu, Emberu a KO.
- Knockout je jednak MVC a co sa tyka rychlosti, tak je skor na pomalsej strane z tejto skupiny
- Angularu 1 by som sa uz teraz vyhol... ked sa mozno o rok, dva zabehne Angular 2, bude mat opat zmysel, ale pokial chces A1 pouzivat na komponentovy layout, tak budes nadavat
- Ember je tiez MVC a dokazes v nom rychlo napisat appku, pokial nepotrebujes urobit nieco krkolomne, vtedy zacnes viac extendovat, ako je prijemne. Ember je velmi opinionated. Na templating pouziva Handlebars, co sa mne vzdy velmi pacilo.
- React vie byt asi najviac MVVM, aj ked je to skor iba V(M) v zaklade, ak vsak prezijes JSX a akceptujes Flux, tak je prijemny na pouzivanie. Miestami sa moze zdat, ze pridavas viac komplexity, ako by si mozno chcel, ale aspon nemusis preliezat mury konvencii, ako v pripade Emberu.

Na aplikacie s vela resourcami, kde nepozadujes velmi fancy fukncionalitu, by som volil Ember a na vsetko ostatne React. Najlepsie ale urobis, ak si urobis nejaky weekendovy projekt v oboch a zistis, co ti viac vyhovuje. Je to naozaj pain vybrat ten spravny a to som teraz nebral do uvahy Mithril, Aureliu, Riot, Polymer alebo Ext JS. Najviac sa mi ale osvedcila jednoduchost v tychto frontendovych FW. Asi aj preto som momentalne na Vue. Pouziva sa lepsie, ako Angular, je rychly, lahko testovatelny, dokazes v nom to, co v Reacte (napr. uz sa pripravuje dokonca aj Vue-Flux) a nezavadzia ti ako Ember

Vdaka za pekne zhrnutie.
Zatial to vyzera ze sa budem rozhodovat medzi Reactom a Ember. Volbu asi bude aj podla podpory Visual Studia, ale momnetalne sa asi proklonim k Reaktu.
Nemas nejaky typ na tu vykendovu aplikaciu na vyskusanie?

@mnichovcan - Urobit to tak mozes, ale je velka sanca, ze budes musiet implementovat business logic aj v PHP a aj v Node. To riesenie, co sme spominali vyssie by ti dalo sancu mat logiku iba v PHP, Node pouzit len na socketovu komunikaciu a napr. s pomocou Vue, by si reagoval na socketove eventy a urobil si UI realtime-ish. Co sa tyka Vue, urcite je to dobry napad na zaciatok Hlavne nezabudni sledovat twitter a github (hlavne issues), nech sa rychlo dozvies o tom, co nove sa prave chysta. A Laracasts urcite sleduj. Ako Slayter povedal, je to skvely resource.

@harrison - Podla mna spravna volba S Visual Studiom ti moc neporadim, ale na web sa mne pacia IDE od JetBrainsu (na React staci WebStorm), pripadne klasicke editory ako Vim, Atom, Sublime Text 3.
Co sa tyka testovacieho weekendoveho projektu, tak to moze byt v zasade cokolvek, ale taka klasika (mimo TODO listu) a je napr. blog. Urobis si co najjednoduhsie API (pozri napriklad toto, mal som s tym naposledy velmi dobru skusenost, pripadne ako rychlu alternativu mozes pouzit free tier na Firebase) a v Reacte urobis frontend. Tymto mas pokryty zakladny REST a pohras sa s komponentami a pripadne aj Fluxom. Dalej mozes uvazovat o pridani komentarov pod clanky. S tym ide dobre registracia + login napr. s JWT. Ak mas stale chut a pripravis si API, ktore zvlada sockety (alebo pouzijes Firebase, ci Pusher), tak mozes pridat nejaku realtime-ish funkcionalitu ako napriklad notifikacie na nove posty alebo komentare.

Aiden napísal:@harrison - Podla mna spravna volba S Visual Studiom ti moc neporadim, ale na web sa mne pacia IDE od JetBrainsu (na React staci WebStorm), pripadne klasicke editory ako Vim, Atom, Sublime Text 3.
Co sa tyka testovacieho weekendoveho projektu, tak to moze byt v zasade cokolvek, ale taka klasika (mimo TODO listu) a je napr. blog. Urobis si co najjednoduhsie API (pozri napriklad toto, mal som s tym naposledy velmi dobru skusenost, pripadne ako rychlu alternativu mozes pouzit free tier na Firebase) a v Reacte urobis frontend. Tymto mas pokryty zakladny REST a pohras sa s komponentami a pripadne aj Fluxom. Dalej mozes uvazovat o pridani komentarov pod clanky. S tym ide dobre registracia + login napr. s JWT. Ak mas stale chut a pripravis si API, ktore zvlada sockety (alebo pouzijes Firebase, ci Pusher), tak mozes pridat nejaku realtime-ish funkcionalitu ako napriklad notifikacie na nove posty alebo komentare.

Vdaka za radu.
Co sa tyka Rest Apri to si viem prakticky vyklikat pomocou Entity Frameworku + Asp.NET Web Api a OData. To je 10 minutova robota.
Bog je pre mna strasna nuda, uz som jeden robil na MongoDb, a nejako som nevidel v tom prinos. Momentalne sa mi skor hodi, nejaky rozcetnik liniek (momentalne si na ich odkladannie pouzivam notepad), kazda linka s popisom, tagmi, fulltext vyhladavanim, potom pridam komentare a nejake autocitavanie ich textu a hodnotenim.