Například Paypal přešel od Javy k NodeJS https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/. Použití rychlejšího jazyka většinou nepomůže. Ten benchmark dává smysl jen pokud používáte nějaké opravdu rychlé uložiště jako Redis.
Zrovna nedavno jsem nekde cetl, ze NodeJS je neuveritelny hype a ze v JVM svete vsechny veci, co umi, davno existuji (nemam zkusenosti, ale neni treba Spring Reactor v podstate ten stejny princip?).
IMO takova Scala + Akka je mnohem lepsi pristup - out-of-box se to da skalovat jak do vice vlaken (podobne jako cluster s NodeJS, akorat bez nutnosti zpetne resit IPC, protoze aktori z principu pouzivaji zpravy) tak na vice stroju (to uz netusim, jestli v NodeJS nejak lehce jde).
Pametova nenarocnost po startu IMO neni zadna vyhoda v pripade enterprise veci, kde za cenu dne prace vyvojare muzu poridit dalsi pakl pameti do servru. A i kdyby JVM potrebovalo 1GB pro start, coz realne nepotrebuje, tak to v prepoctu ta pamet vyjde na par stovek, to se asi bavime o nejakych pidi projekticich, kdyz se resi kazdy megabajt pameti zabirany VM, ktery se navic nezvetsuje s pametovymi pozadavky aplikace... Rychly start to stejne (v benchmarksgame to merili a bylo to tusim spise par stovek milisekund) - co je par (i kdyby desitek) sekund proti uptimu servru a aplikace? Pokud je navic start kriticky, tak se proste prihodi SSD nebo se udela nejaka magie s hotswapovanim trid. Jedina situace, kde to je opravdu vyhoda, jsou shell skripty*, ale tady se bavime o backendu webove aplikace a od te se neocekava, ze se bude spoustet vicekrat nez (strelim od pasu, realne asi jeste mene casto) jednou za tyden.
*: I to ale lze resit, existuje napr. NailGun, ktery udrzuje "zhave" JVM a spoustenou aplikaci mu jen prideli, takze start aplikace je instantni (po skonceni behu aplikace se JVM recykluje).
Rozhodně je příjemnější když tyhle problémy řešit nemusíte.
Toz zmeril jsem to a hello world vychazi takto:
OpenJDK 1.8 - 17MB
Python 2.7.5 - 4MB
VPS se snad bezne ani po par mega pameti stelovat neda, takze tu nevidim zadne problemy k reseni - proste placnu minimalnich 1GB a ono to svete div se staci i pro Javu.
Aha, vy stale mluvite pouze o CRUD? Na to ale snad neni ani potreba specialni BE a staci nejake hotove reseni typu "Backend as a Service". Treba projekt, na kterem nyni pracuji, ma webovy rypak a rozhodne to neni jen a pouze CRUD - podle nejakeho algoritmu se ruzne updatuji tabulky a synchronizuje se to s dalsi sluzbou podle toho, jake uzivatel udela zmeny.
Podle popisu je ten projekt stále jen CRUD.
Hmm, takze desitky minut pocitani pomoci nejakeho proprietarniho algoritmu je podle vas CRUD jak vysity? Tak to asi vlastne nemame jine ulohy nez CRUD, kdyz kazdy ukol musi data cist a plivat => CRUD, ze?
Ne, databaze to opravdu nepocita...
No vidíte, a přitom existují obří firmy s tisíci vývojáři, kteří opouštějí .NET/Javu a přechází třeba na node.js nebo Go.
Tady je zrovna aktuální článek:
https://blog.risingstack.com/node-js-examples-how-enterprises-use-node-in-2016/
A taky existuji firmy jako Twitter, kteri presli z duvodu vykonu k JVM. Ja nerikam, ze to nejde delat v NodeJS, jen ze si myslim, ze je to spatny nastroj, pro vyvoj "ve velkem".
Osobně si myslím, že statické typování má velký význam, ale na druhou stranu si nemyslím, že je to spása na všechny problémy. Pokud tady někteří propagují, že se statickým typováním nemusí psát unit testy, tak to je naprosté nepochopení funkce unit testů.
Jestli to "nekteri" je na mne, tak ja nepsal, ze staticke typovani plne nahrazuje unit testy. Ja psal, ze bez statickeho typovani musite psat testu mnohem vice, testu, ktere by se psat manualne nemuseli, kdyby se pouzil staticky jazyk.
Zobrazit příspěvky
.
.
