Dnes se podíváme na zoubek novému frameworku koa. Koa je lehký serverový framework, který používá ECMA6 generátory pro tvorbu middleware. To má několik důsledků, například se v aplikaci nevyskytují nepřehledné callbacky a middleware se chová jako skutečný middleware, tedy může provádět akce před i po předání řízení nižším vrstvám aplikace.
Jestli jste někdy řešili nasazování aplikace, asi víte, že všechno odladit může být celkem zdlouhavá záležitost. Dokážete si představit, že na to máte jen týden? Že je to nemožné? Není! Jde to a ani to nemusí být příliš složité.
Reportáž z virtuální konference FOSDEM. Minule jsem popsali Go room, dnes se věnujeme monitoringu a observability.
Mikrofrontendy jsou zajímavá adaptace konceptu microservices pro potřeby frontendového vývoje. Podívejte se, co to v praxi obnáší a proč jsme se v Seznam.cz rozhodli vyvinout náš vlastní microfrontend framework, Merkur.
n versus nvm
Je nejaka vyhoda pouzit
nproti podle me rozsirenejsimunvm?Na n jsem narazil dříve, pravděpodobně to je jedno.
Re:
Jen je potreba to poustet trochu jinak pomoci:
NODE_ENV=development PORT=3000 DEBUG=* nvm run v0.11.12 --harmony app.js
nvm místo n
Díky za tip
Výhody oproti jiným
Chtěl bych se zeptat, jaké výhody (klidně osobní názor) má koa oproti jiným frameworkům jako třeba Sails, Meteor nebo třeba geddy? Nikdy jsem v koa ani v expressu nic pořádného neudělal a teď objevuju Sails, ale pořád mi koa připadá moc low-level, kdežto třeba právě v Sails mám rozvrženou architekturu, modely, ORM, automatické routování na controllery, a tak dále. Možná je ta výhoda právě v té úplné svobodě. Možná to vyplívá z určité lenosti, ale podle mě je pohodlnější používat nějakou nadstavbu, která může mít třeba právě koa jako takové jádro.
Re: Výhody oproti jiným
Dobrá otázka.
Express je vlastně taková nadstavba nad connect (+ velice jednoduchý scaffold, který se časem opět odštěpil). Vše důležité je udržováno v connectu a pokud se middleware ukázalo jako „věc názoru, preference,“ přechází potom do express a tam se opět časem vyštěpí do samostatného mudulu (příkladem třeba může být
connect.multipart())Koa je nástupcem expressu a connectu v tomto smyslu. Jeden z hlavních vývojářů (TJ Holowaychuk) je také iniciátorem tohoto projektu.
Koa se nesnaží v současné době nahradit express ani connect (vysvětlení zde), pouze jde dál a používá nové jazykové prostředky, jak tomu je u mladých (nebo přelomových technologií). Porovnejte například .NET 1.1 a 3.5. Proto pořád v perexu to ECMA6 (no, vlastně jen generátory). Snaha je ukázat, že to jde jinak/lépe již se „stávajícími standardy“
Sails je oproti tomu komplexní framework včetně scafoldu, který začátečníkovi nabízí vše co ho napadne.
Comet je oproti tomu úplně jiný přístup k celé aplikaci. Tímto směrem se se ubírá Meteor.
Můj osobní názor je, že se technologie v určitých oblastech bude posouvat směrem k Meteoru, ale netřeba nyní spěchat. Dan Steigerwald (snad to mohu prozradit) se v blízké době chystá psát o Reactu v souvislosti s Polymerem a Angularem, tak se budu těšit…
Musím přiznat, že Meteor mě hodně zaujal jak pozitivně tak i negativně, ale to už je ta věc názoru :-)
Re: Výhody oproti jiným
Omlovám se, zapomněl jsem reagovat na geddy. Neznám, ale vy padá to zajímavě. Má spoustu použitých modulů a mezi nimi třeba i socket.io.
Můžeš uvést pár odkazů na přiklady? Možná, jestli máš zkušenost, nebylo by marné napsat krátký článek nebo zprávičku! :-)
Re: Výhody oproti jiným
Díky za rozsáhlou odpověd. Koncept middleware, jak je chápan v connect/express/koa a implementován formou
use, je vážně dobře vymyšlen. Jen tak na okraj, nedávno jsem narazil na tohle, což mi přijde docela brutální.Jinak s těmi novými jazykovými prostředky, takovéto probublávání requestu dolu a zpátky nahoru pomocí
yield, to mě vážně zaujalo. A třeba časem přijdou s dalšími novinkami z ECMAScriptu 6, uvidíme.Se Sails jsem teď začal, protože mě baví Angular a potřebuji jenom backend, který mi vytvořit v Sails přijde velmi pohodlné, protože je tam právě vše předpřipraveno. A začlenení socket.io má taky zajímavé. Protože jestli jsem to správně pochopil, nabízí i klientskou knihovnu a spolu umí vytvořit Real-time REST nebo jak to nazvat.
Meteor se mi taky líbí a jeho propojení serveru s klientem je vážně super (díky za odkaz na Comet). Taky jsem ho zkoušel, a přijde mi docela uzavřený, nic moc k nakonfigurování. Ale nic pořádného jsem v něm nevytvořil.
A co se týče geddy, tak ten jsem bohužel ani nezkoušel, pouze jsem na něj narazil, tak jsem ho uvedl jako příklad. Takže odkazy bych uvést mohl, ale jen bych googlil. Každopádně o Sails, až ho pořádně prozkoumám, bych článek napsat klidně mohl, kdyby byl zájem :-).
Re: Výhody oproti jiným
Taky mě teď napadlo, že ta provázanost klienta se serverem v Meteoru nám neumožňuje styl napsat si backend a ten používat např. pomocí RESTu na více klientech (browser, iOS, Android, …). Nebo to tak není?
Prostě všechno má svá pro a proti. Každopádně, vím, co jsem potřeboval, díky.
Tak to je vážně síla :-D Takový kód/modul raději vyloučit na začátku. Jistě to lze vyřešit lépe i bez použití nějakého promise modulu, například pojmenováním funkcí.
chrome://flags/#enable-javascript-harmony) a tento stav potrvá, dokud nebude ES6 dokončenaDobrá zpráva ale je, že už dne tu je traceur, takže novinky lze používat již nyní ale rychlost a efektivita bude pravděpodobně nižší.
Ano, to je nevýhoda, nevím jakým způsobem to Meteor řeší, ale programátor by to měl řešit segregací modelu a aplikační logiky. Meteor je ještě mladý a neotestovaný a potenciálně nebezpečný pro nezkušeného programátora (vynesení aplikační logiky na veřejnost), jistě není vhodný na veřejně dostupné účetní a bankovní aplikace