1. Pro zakladni rozvrzeni projektu vc submodulu je Gradle 1:1 to same co Maven
2. S tim rozdilem ze Gradle neumi definovat Parenta
3. S tim rozdilem ze Gradle je mene zaboilerplatovany, jenze jaksi za cenu toho, ze clovek nema naseptavani.
4. S tim rozdilem, ze v Gradlovi se da dobre programovat - to je snad ta nejhorsi vlastnost, protoze by to nekoho mohlo napadnout delat. Co potrebujete pri buildu programovat?
Ad 1) Jenom dokud máte prázdný projekt. A vlastně už ani to není pravda, Gradle zavedl rozdělení závislostí na
api a
implementation, takže konečně tranzitivní závislosti dávají smysl.
Ad 2) Gradle samozřejmě parenta nadefinovat umí. A umí, cokoli chcete – je to jen kód. Takže si můžete parenta udělat, jak chcete – můžete z něj dědit, co chcete, můžete si to parametrizovat, můžete si parenty třeba přepínat, když budete chtít.
Ad 3) IntelliJ Idea v Gradle skriptech našeptávat umí.
Ad 4) To, že můžete v buildskriptu programovat, je obrovská výhoda. Potřebujete to vždy, jakmile nejde jen o nějaký školní projekt. Stačí se podívat, kolik pluginů pro Maven vzniklo. Build chcete upravovat v závislosti na prostředí, kde poběží, chcete tam integrovat informace z VCS, chcete publikovat balíčky a dokumentaci, mimifikovat a komprimovat soubory, podepisovat, a milion dalších věcí, u každého projektu jiné. Když můžete v buildskriptu programovat, nepotřebujete různé šílené CI nástroje, které „naprogramujete“ (ideálně klikáním ve webovém prohlížeči), protože jediné, co od CI potřebujete, je spustit příslušný Gradle task. A co potřebujete si naprogramujete v něm.
1. Zkousel jste si uz zbuildit ten Micronauti Lambda example na Githubu s GraalVM? Vzdyt to je hrozne, kompilace tim Graalem trva snad 3 minuty.
2. Kdyz jsem videl nejaky benchmark, tak to stejne melo pomalejsi cold start nez Node.js lambda.
3. Na takovou monolitickou lambdu rovnou muzete pouzit Spring Cloud Function - nevim jen jestli tu v budoucnu bude podporovat Graal.
4. Ikdyz to vsechno udelate, tak budete tvorit relativne velke monoliticke lambdy a ja se ptam - proc to do haje radeji rovnou nerozjet jako service v docker kontejneru? Co tim ziskate ze to bude lambda funkce?
Ad 1) Vašemu CD nástroji to nějak vadí, stěžuje si, že mu to trvá 3 minuty?
Ad 2) No jo, jenže Node.js už má za sebou roky optimalizací rychlého startu, GraalVM je ve stavu, že už to jde nastartovat a běží to. Optimalizace teprve přijdou.
Ad 3) a 4) Pokud vytváříte „monolitickou lambdu“, je chyba ve vás, ne v nástrojích.
Výhoda je ta, že mám vše na jedné platformě. Takže můžu mít aplikaci, která se skládá z jednoho nebo více monolitů, kolem se mohou motat mikroslužby a nějaké nárazové prkotiny můžu řešit lambdou. A pořád mám jednu platformu a jeden zdrojový kód, takže můžu sdílet implementaci a přelívat ji tam, kam zrovna potřebuju. Chci vytrhnout z monolitu část a nadělat z ní mikroservisy? Jasně, není problém, nemusím nic programovat znova, jenom implementaci upravím pro jiný způsob běhu. Přestane lambda stačit? Nevadí, udělám z ní mikroservisu.
Jave tim ujel vlak a muj nazor po X hodinach googleni je, ze to jeste nedohnala.
Nemyslím si, že povědomí o současných technologiích lze získat googlením.
A pokud GraalVM nepohne pri rychlosti buildu zadeki, tak ani nedozene.
Jenže rychlost buildu do nativního kódu nikoho nezajímá. Vybral jste tu jedinou operaci, která nebrzdí nikoho důležitého – ani programátory, ani uživatele. Pro programátory je důležitá klasická kompilace do bajtkódu a start aplikace, kompilace do nativního kódu je nezajímá. A pro uživatele je důležitý běh aplikace.
Nicmene reseni b mohlo byt jine, a sice jinaci JVM. V Lambde vam je burt nejaka performance vyjma cold startu. Pomale to muze byt klidne jako python. Hlavne at se ta mrcha lina rychle nastartuje.
Ta jiná VM se jmenuje SubstrateVM a je právě součástí GraalVM. Už teď je start dost rychlý, a věřím, že se bude dál zrychlovat – protože optimalizovat ho dává smysl, na rozdíl od optimalizace rychlosti release buildu.
Zobrazit příspěvky
