Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Radek Miček 18. 02. 2017, 14:29:44
-
Jaké jsou vaše zkušenosti s vývojem a provozem webových aplikací postavených v jazycích Erlang/Elixir.
-
nauc se cowboye a udelas v tom cokoliv. my jeli cca od 2011 chicagoboss s vlastnim db backendem (dsl na datamodely kompilovany do beamu a nativnich query procedur pro db) a pak jsme presli na vlastni odlehceny framework postaveny na cowboyi, websocketech, reactu a es6. cele to jede v docker containerech (zacinali jsme na lxc) nad zfs a management je velmi blizko nule.
ted leti phoenix ale elixir je spis takovy lakadlo pro rubysty, erlang je erlang :)
-
Jaké jsou vaše zkušenosti s vývojem a provozem webových aplikací postavených v jazycích Erlang/Elixir.
S vývojem jsou moje zkušenosti skvělé (Phoenix framework). Co se týče nějakého většího nasazení, neumím posoudit, dělám věci víceméně jenom nástroje pro sebe a omezený okruh lidí. Ale s tím by taky neměl být žádný velký problém, možná to chce jenom aby si logiku Erlangu opsáci trochu nastudovali, aby věděli, jak se k tomu chovat...
Kdyžtak zkus nahodit nějaké konkrétnější dotazy, rád pomůžu, jestli budu vědět, Elixir je moje láska :)
ted leti phoenix ale elixir je spis takovy lakadlo pro rubysty, erlang je erlang :)
Elixir rozhodně není jenom o syntaxi. I když i ta ušetří hodně nervů (osobně jsem syntaxi Ruby nesnášel a díky Elixiru jsem si na ni zvykl, ne naopak). K psaní v plain Erlangu moc nevidím důvod, Elixir je super.
Phoenix je výborný framework, dal bych mu rozhodně před ChicagoBossem přednost (v Phoenixu jsem dělal hodně - od ranných fází vývoje, v CB něco málo). Ale je fakt, že jeho síla je hodně v tom klasickém modelu oddělených stránek generovaných na serveru šablonami. Websockety má taky pořešené parádně, takže SPA se s ním taky dá udělat příjemně, ale už to není mainstreamové použití, které je fakt odladěné.
Mám rozchozenou SPA aplikaci, kde Phoenix vyloženě jenom obsluhuje websockety, rendering se dělá na klientovi (v Elmu, ale stejně dobře se dá použít třeba i React). HTTP API v téhle aplikaci vůbec nemám, všechno valí přes ws a funguje to dobře.
-
Websockety má taky pořešené parádně, takže SPA se s ním taky dá udělat příjemně, ale už to není mainstreamové použití, které je fakt odladěné.
Jak souvisí SPA s websockety?
-
Jak souvisí SPA s websockety?
Když se stránky renderují na klientovi, musí klient nějak dostat data. Buď přes http api, nebo přes ws. Ws mají výhodu v tom, že je přes ně čistější oboustranná asynchornní komunikace. Takže když SPA, tak mi websockety přijdou jako lepší volba (pokud se s nimi v daném frameworku dobře pracuje).
-
S vývojem jsou moje zkušenosti skvělé (Phoenix framework). Co se týče nějakého většího nasazení, neumím posoudit, dělám věci víceméně jenom nástroje pro sebe a omezený okruh lidí. Ale s tím by taky neměl být žádný velký problém, možná to chce jenom aby si logiku Erlangu opsáci trochu nastudovali, aby věděli, jak se k tomu chovat...
Kdyžtak zkus nahodit nějaké konkrétnější dotazy, rád pomůžu, jestli budu vědět, Elixir je moje láska :)
Zeptám se tedy konkrétněji k Phoenix frameworku:
- Jak je to s upgrady na novou verzi? Bývá potřeba měnit aplikaci nebo jsou nové verze zpětně kompatibilní?
- Pro přístup k databázi používáte Ecto? A pokud ano, jak dobře se v tom píší složitější dotazy?
-
Jak je to s upgrady na novou verzi? Bývá potřeba měnit aplikaci nebo jsou nové verze zpětně kompatibilní?
To je různé podle verze. Ze začátku byl vývoj docela bouřlivý, ale teď už je nějakou dobu řekl bych stabilizovaný. Žádné překotné změny bych teď už nečekal, podle mě už bude Phoenix hodně stabilní. Taky z toho důvodu, že z hlediska toho, co umí nejlíp (aplikace založená na oddělených stránkách, templatování) už imho není zas tak moc co vymýšlet :)
Způsoby upgradu na jednotlivé verze je zdokumentovaný, můžete se kouknout sám: http://www.phoenixframework.org/blog/upgrading-from-11x-to-120
Pro přístup k databázi používáte Ecto? A pokud ano, jak dobře se v tom píší složitější dotazy?
Zatím jsem psal věci, kde se mi hodilo jako úložiště použít Mnesia (interní erlangovská databáze), kterou Ecto nepodporuje, takže s Ecto neporadím, zkoušel jsem to snad jenom jednou a velmi krátce.
-
ake IDE viete doporucit na Erlang / Elixir? Idealne aj s nasepkavacom
-
ake IDE viete doporucit na Erlang / Elixir? Idealne aj s nasepkavacom
Vim. Našeptávač asi neexistuje - na Erlangu nemůže nikdy dobře fungovat, protože moduly je možné (un)loadovat za běhu. Proto funguje našeptávání jenom v shellu, připojenému ke konkrétnímu běžícímu VM.
-
ake IDE viete doporucit na Erlang / Elixir? Idealne aj s nasepkavacom
Vim. Našeptávač asi neexistuje - na Erlangu nemůže nikdy dobře fungovat, protože moduly je možné (un)loadovat za běhu. Proto funguje našeptávání jenom v shellu, připojenému ke konkrétnímu běžícímu VM.
Našeptávač pro Elixir existuje https://github.com/tonini/alchemist-server . V Emacsu stačí nainstalovat balíček alchemist.
-
Do idei existuje erlang aj elixir pligin
-
Jak souvisí SPA s websockety?
Když se stránky renderují na klientovi, musí klient nějak dostat data. Buď přes http api, nebo přes ws. Ws mají výhodu v tom, že je přes ně čistější oboustranná asynchornní komunikace. Takže když SPA, tak mi websockety přijdou jako lepší volba (pokud se s nimi v daném frameworku dobře pracuje).
IMHO pro komunikaci typu požadavek-odpověď se websockety moc nehodí.
-
Jak souvisí SPA s websockety?
Když se stránky renderují na klientovi, musí klient nějak dostat data. Buď přes http api, nebo přes ws. Ws mají výhodu v tom, že je přes ně čistější oboustranná asynchornní komunikace. Takže když SPA, tak mi websockety přijdou jako lepší volba (pokud se s nimi v daném frameworku dobře pracuje).
IMHO pro komunikaci typu požadavek-odpověď se websockety moc nehodí.
proč? mi to docela funguje
-
proč? mi to docela funguje
Třeba protože v HTTP mám spárovanou odpověď s požadavkem zadarmo? Proč používat statefull řešení tam kde není potřeba udržovat stav?
-
proč? mi to docela funguje
Třeba protože v HTTP mám spárovanou odpověď s požadavkem zadarmo? Proč používat statefull řešení tam kde není potřeba udržovat stav?
to "zadarmo" bych si dovolil zpochybnit, že není potřeba udržovat stav taky IMHO neplatí vždy, pro mě je přirozené, že aplikace naváže spojení spojení se serverem a po skončení aktivity uživaetle sezení uzavře
-
Třeba protože v HTTP mám spárovanou odpověď s požadavkem zadarmo? Proč používat statefull řešení tam kde není potřeba udržovat stav?
To neni zadarmo. To je za cenu udrzovani dvou ruznych API (ws a http).
-
Třeba protože v HTTP mám spárovanou odpověď s požadavkem zadarmo? Proč používat statefull řešení tam kde není potřeba udržovat stav?
To neni zadarmo. To je za cenu udrzovani dvou ruznych API (ws a http).
Websockety se dají používat jen pro vyvolání akce načtení dat přes HTTP API. K žádné duplikaci potom nedochází.
-
Proč FP programátoři prosazují bezestavovost na úrovni jazyka a stavovost na úrovni fungování aplikace?
-
Proč FP programátoři prosazují bezestavovost na úrovni jazyka a stavovost na úrovni fungování aplikace?
Spis pure (eliminaci side-effektu), stavovosti se neda vyhnout. Uz tady je videt pekne proc. Co je stavove a nestavove ? Pokud to ma neco delat, tak to musi menit stav. Jde o to, aby zmeny stavu meli urcite vlastnosti a dalo se o nich lepe premyslet.
Prekladac si pak muze udelat vesmes co chce za danych garancych.
A pokud tak zapatram v pameti, tak i v Ruby a Jave neplati ze je to bezstavove. Volani je bud deterministicke, nebo nedeterministice. Nam jde o deterministicke, ktere samozrejme ulehci praci prekladaci, dovoli daleko lepsi cachovani atd.
V Ruby a Jave se programuje, tak ze se drzi stav v databazi.
Naopak v OTP se da takhle programovat taky, ale ... prave diky garancim mas tu databazi o jeden krok bliz.
Prakticky to mame nasazene celosvetove, odezvy v radech stovek micro sekund. Alchemist, VSCode ma taky extension. Naseptavace se moc nepouzivaji, moduly se pisou malinke...
Proste OO udelano spravne a microservice taky.
-
stavovost na úrovni fungování aplikace
co to vlastně znamená?
-
By ma velmi zaujimalo, kolki z vas realne pouzivaju funkcionalne jazyky ako profesionalny jazyk, s ktorym pracuju
-
By ma velmi zaujimalo, kolki z vas realne pouzivaju funkcionalne jazyky ako profesionalny jazyk, s ktorym pracuju
haskell na některé nástroje, občas i velké, pro "produkci" ovšem ne
-
Websockety se dají používat jen pro vyvolání akce načtení dat přes HTTP API. K žádné duplikaci potom nedochází.
Nepsal jsem "duplikace", ale dvě různá API. Typicky si na začátku říkáš, že tyhle data přece načteš jenom jednou, takže na to použiješ HTTP, ok, napíšeš to a za půl roku zjistíš, že bys vlastně chtěl, aby ty data byly živý - a přepisuješ to znovu do ws, s úplně jinou logikou, takže se ten kód nedá moc znovupoužít. Protože jsem si tímhle prošel, dospěl jsem k názoru, že nejjednodušší je prostě všechno posílat přes ws a fertig.
Proč FP programátoři prosazují bezestavovost na úrovni jazyka a stavovost na úrovni fungování aplikace?
Mícháš dvě věci dohromady: vedlejší efekty a stavovost. "Sémanticky", význámově "stavová" může být i čistá funkce, třeba když jí jako první parametr dám stav. Taková funkce je čistá (nemá vedlejší efekty) a přitom pracuje se stavem (ještě líp možná "kontextem").
Stavovost "ná úrovni aplikace", resp. spíš komponenty, je prostě daná povahou toho, co ta komponenta dělá. Pokud servíruju statické stránky, pořád vracím stejnou stránku na stejný dotaz, tak mám nestavovou komponentu. Pokud chci, aby v hlavičce stránky bylo jméno uživatele, tak je to prostě komponenta stavová z principu - s jazykem to nemá nic společnýho.
-
Docela zajímavá je otázka vytížení serveru - pokud mi víc lidí přistupuje na živé informace, tak když to rozumně navrhnu před REST, tak tam můžu dát HTTP caching reverse proxy; u WS řešení bude výsledkem velké množství simultánních spojení. Nikdy jsem to nedělal (zrovna mám rozdělaný jeden projektík, kde jsem to původně přes WS chtěl řešit), ale nemůže to být trochu problém?
-
Docela zajímavá je otázka vytížení serveru - pokud mi víc lidí přistupuje na živé informace, tak když to rozumně navrhnu před REST, tak tam můžu dát HTTP caching reverse proxy;
Živá data stejně typicky cachovat nemůžeš, protože neznáš expiraci.
ale nemůže to být trochu problém?
Může. Ale erlang se dá dost snadno clusterovat a websockety v Phoenixu jsou na to od začátku navržené, takže se dá jít i touhle cestou. A přinejhorším kritické části můžeš do toho http vždycky přepsat - ale až to reálně bude výkonnostní problém, ne předem.
Viz https://dockyard.com/blog/2016/01/28/running-elixir-and-phoenix-projects-on-a-cluster-of-nodes
https://groups.google.com/d/msg/phoenix-talk/zjwitSVACUc/7gh8q9hBDgAJ
-
Pokud to ma neco delat, tak to musi menit stav. Jde o to, aby zmeny stavu meli urcite vlastnosti a dalo se o nich lepe premyslet.
Prekladac si pak muze udelat vesmes co chce za danych garancych.
Je zajímavě, že si v tom samém příspěvku odporuješ: Překladač nepracuje se stavem, a přesto rozhodně něco dělá :-)