Összehasonlítás a Vulcan és az AUSK között: a Node, React és a GraphQL teljes kihasználása

Az NRG verem a gyorsabb fejlődés érdekében

Valószínűleg még soha nem hallott sem a Vulcan.js-ről, sem az Apollo Universal Starter Kit-ről - legalábbis még nem.

De biztos vagyok benne, hogy hallottál már a React-ről, a Node.js-ről és a GraphQL-ről. Oké, ezt nevezzük alábecsülésnek: valószínűleg milliónyi tweetet, blogcikket, találkozót és podcastot látott erről a háromról és azok varázserejéről.

Nagyon sok jó oka van annak, hogy a webfejlesztők dicsérik ezeket a technológiákat. Mégis, ha valaha megpróbált egy teljes, teljes veremű JavaScript alkalmazást írni a semmiből, akkor észrevehette, hogy mennyi kazánlemezt képes előállítani.

Ez különösen az általános funkciókkal kellemetlen: hitelesítés, adatbázis beállítása, az alkalmazás fő összetevőjének beállítása, a beállítások megadása ...

A Vulcan.js és az AUSK egyaránt arra törekszik, hogy egy gyors és hatékony full-stack JavaScript-fejlesztővé váljon. Mindkettő moduláris architektúrára támaszkodik, a React az UI-hez, a Node a háttérprogramhoz és az Apollo graphQL az ügyfél / szerver kommunikációs réteghez. Mindkettő rengeteg előre kódolt modult tartalmaz, így az értékes funkciókra összpontosíthat.

Ugyanakkor mindegyikük nagyon eltérő megközelítést alkalmaz a problémára, ezért úgy gondoltam, hogy élvezheti az összehasonlítást.

Először mutassuk be a versenyzőket.

Jogi nyilatkozat: A Vulcan.js közreműködője vagyok, azonban mindkét technológiát felhasználtam az ügyfelem projektjeiben, így a lehető legobjektívebb maradok.

Apollo UNIVERSAL kezdőkészlet

Oké, ha egyetemesnek mondják, akkor egyetemesre gondolnak. Láttál már olyan JavaScript kazánt, amely Scala szervert tartalmaz a nagy munkához? És egy teljes React Native beállítás az Expo segítségével? Még az örök (és bosszantó) Szög kontra React vitát is lezárják, támogatva mindkettőt.

Nincs sok más mondanivalóm. Úgy értem, nézze meg újra ezt a verem, ez egy webfejlesztő legmerészebb álma!

Valójában van mit hozzáfűznöm: a Bootstrap és az Ant Design is szerepel stíluskeretekként, a Knex az SQL-adatbázishoz való csatlakozáshoz (a MongoDB kapcsolatot nem tartalmazza, de könnyen kivitelezhető), és ez TypeScript-be van írva. A JS / GraphQL alkalmazás összes alapvető jellemzőjét a kazánlap tartalmazza (menü, hitelesítés stb.) + Néhány magasabb szintű modul, amelyek példaként szolgálnak.

Link: //github.com/sysgears/apollo-universal-starter-kit

Vulkán: univerzális, izomorf

Emlékszel a meteorra és a távcsőre? Tudom, hogy a JS ökoszisztéma gyorsan mozog, de ez az aranykorszak olyan volt, mint csak 2 vagy 3 évvel ezelőtt.

A Meteor volt az első keretrendszer, amely teljes mértékben kihasználta a szerveroldali és kliensoldali JavaScript kombinációját, lehetővé téve mindkét környezetben futó izomorf kód írását. A Telescope egy Meteor kazánalkalmazás volt, amelynek célja, hogy teljes mértékben élvezhesse csomagorientált architektúráját.

Habár a Meteor továbbra is számos professzionális alkalmazásban használatos, és rengeteg fejlesztő ismeri, bizonyos technikai korlátok megbénítják, amelyek megakadályozzák a szélesebb körű felhasználást: webpack-kompatibilis felépítési rendszere, csomagkezelője, amelyet most felülmúl az NPM, vagy RAM valós idejű adatcsere-protokoll fogyasztása.

És még nem fedeztem fel egy olyan keretet, amely fele olyan produktívvá teszi a fejlesztőket, mint a Meteor. De ne aggódj, most komoly versenyző van. Érted: Vulkán!

Az Apollo GraphQL és a racionális csomagorientált architektúra használata lehetővé teszi a Vulcan számára, hogy legyőzze Meteor korlátait, miközben ugyanazokat az előnyöket élvezi: teljesen moduláris architektúra, deklaratív programozás, izomorfizmus és így tovább.

A Vulcan a JavaScript ökoszisztéma Rails-je. Könnyű elindítani, de elég teljes ahhoz, hogy bármilyen alkalmazást megírhasson.

Az előző cikkemben olvassa el a fejlesztési sebességet célzó Vulcan minták teljesebb leírását.

Link: //vulcanjs.org/

# 1: Keret VS kazán

Első fő különbség ezek között az eszközök között: Az AUSK egy kazán, míg a Vulcan egy keret. Hol lehet a megkülönböztetés, elgondolkodhat?

Vulkán, egy keret

A keretrendszer célja, hogy napi szinten hatékonyabb fejlesztővé tegye Önt egy speciális funkció- és segítőkészlet biztosításával. Általában úgy tervezték, hogy külön maradjon az alkalmazástól. Alkalmazását időről időre frissítheti, valahányszor a keretrendszer új verziója jelenik meg.

Általában a specializáció szintje alapján különböztetünk meg kereteket és mérlegeket. A keretrendszer általában lehetővé teszi üzleti szintű szolgáltatások nyújtását, míg a könyvtár egy speciálisabb technikai eszköz. De mindkettő többnyire ugyanúgy működik.

A keretrendszerekkel vagy libekkel az a korlátozás, hogy elveszettnek érezheti magát, amikor elhagynak. Mit csinálsz, ha a hiba nem az alkalmazásodban található, hanem a Reactben vagy az Apollóban?

Az az alapszabályom, hogy egy keretrendszer használatakor készen kell állnia arra, hogy hozzájáruljon annak fejlesztéséhez, legalábbis azzal, hogy problémákat nyit meg, amikor hibával találkozik.

AUSK, kazán

A kazánlap egy jól megírt kóddarab, teljesen működő fejlesztői környezettel. Ez minden. A kazánlemezzel nehezebb lépést tartani a frissítésekkel, mert a kazánlap kódja nincs egyértelműen elválasztva az alkalmazásától. Olyan, mint a React App létrehozása a kiadás után.

Általában csak néhány egyedi módszert kínál. Az első hónapban gyorsabban fogja érezni magát, és kihasználhatja a csatában tesztelt architektúrát, de az utazási sebessége többnyire ugyanaz lesz, mint kazán nélkül.

A kazánlemez sokkal nagyobb szabadságot jelent, mint egy keret, ugyanakkor kevésbé befolyásolja a hatékonyságot.

# 2 Tanulási görbe

Vulcan: A GraphQL egyszerűvé vált

A Vulcan jó módszer lehet a GraphQL első megismerésére, mert… nem kell valójában a GraphQL-t írni. A keretrendszer az adatmodell alapján generálja az Ön számára a GraphQL sémát és a felbontókat. Fejlesztői eszközök, például a GraphiQL vagy a GraphQL Voyager használatával vizualizálhatja és kijátszhatja a sémát, hogy megértsék, hogyan alakulnak át szolgáltatásai a GraphQL-be.

A második lépés a Vulcan logikájának megértése. A „Vulcan Starter” alkalmazás egy élő oktatóanyagot tartalmaz, amely segít a folyamatban.

AUSK: purisztáknak

Az AUSK architektúra sokkal közelebb áll ahhoz, amit az Express fejlesztők megszoktak. Gondoljon a kanonikus Express alkalmazására, de telepítve legyen a GraphQL és a csomagalapú architektúra. Semmi meglepetés.

Ez azt is jelenti, hogy meg kell értenie a GraphQL alapjait az AUSK használatához, természetesen a Node, az Express és a React, valamint a használt adatbázisok mellett (de ugyanez vonatkozik a Vulcan-re is). Szerencsére néhány példát tartalmaz, amelyek segítséget nyújtanak a folyamatban, ideértve az adatok létrehozását és felsorolását, sőt a fájlok feltöltését is.

Következtetés: A full-stack fejlesztőknek sokat kell elsajátítani

A JavaScript ökoszisztéma egyre jobban érik, ami azt is jelenti, hogy a kezdők számára nehezebb megtanulni és megérteni.

Ahhoz, hogy teljes mértékben élvezhesse ezeket a technológiákat, szüksége lesz legalább a modern JavaScript és a React fejlesztés ismeretére.

Ne számítson arra, hogy az első napon teljesen produktív lesz. Ennek ellenére rengeteg, ingyenes vagy fizetős tanfolyam létezik a modern, teljes veremű JavaScript fejlesztés elsajátításához. Az AUSK és a Vulcan tanulmányozása hihetetlen ihletforrás lehet.

# 3 Fejlesztési sebesség

Vulcan: automatizáljon mindent

Ha jól használják, a Vulcan hihetetlenül gyorsan nyújt funkciókat. Ez azért van, mert sokat támaszkodik az automatizált előállításra, így néhány óra alatt képes előállítani az alkalmazás legrelevánsabb részeit, mindaddig, amíg az adatmodellje megfelelően van meghatározva.

Ezt a mintát deklaratív programozásnak hívják: Ön „kijelenti” az alkalmazás működését, és hagyja, hogy a keretrendszer elvégezze a munkát. Nehéz megvalósítani, de rendkívül erős lehet.

AUSK: több szabadság

Mivel az AUSK kazánlemez-központú, egy kicsit nehezebb az alapvető funkciók hozzáadása, mivel ez egy többlépcsős folyamat:

  • írja meg a GraphQL sémáját
  • ugyanaz a felbontóknál, mutációknál
  • az adatbázis-modelljével azonos (a Knex vagy a Mongoose használatával)
  • ugyanaz a React komponenseivel

Azonban,ha egyéni funkciót kell írnia, akkor az AUSK-val könnyebb lesz, mint a Vulcan-nal. Tehát, ha nagyon kevés adatmodellje van, de összetett szolgáltatásai vannak, az AUSK hatékonyabb lesz, mint a Vulcan.

Remélhetőleg folyamatban van az AUSK deklaratívabbá tétele az innovatív Domain Driven Design által inspirált sémarendszer, a domain-séma révén.

Következtetés: válassza ki a megfelelő eszközt a megfelelő használati esethez

A varázslatos JS fejlesztéshez nincs mágikus univerzális technológia. Az egyes keretek fejlesztési sebessége nagyban függ az alapul szolgáló felhasználási esettől. Az adatorientált platformokhoz és a professzionális eszközökhöz általában a Vulcan alkalmazást preferálom, a B2C SaaS platformokhoz pedig az AUSK-ot, amelyek több egyedi funkciót igényelnek.

# 4 Közösség, támogatás és érettség

Vulcan: a Meteor örököse

A Vulcan egy keretrendszer Sacha Greif-től, aki hosszú ideje fejlesztette a Meteor-t, és nagyon sokat fektetett be a JavaScript-közösségbe (többek között a JS állapota és a CSS állapota).

Van egy aktív Slack, ahol a kezdők és más rajongók gyorsan megtalálják a választ a kérdéseikre.

AUSK: aktívan karbantartott projekt

Az AUSK-t a SysGears tartja fenn, különösen Victor Vlasenko, a cég alapítója.

A projekt a Gitterhez kapcsolódik. Az AUSK-val folytatott legutóbbi szabadúszó küldetésem során Victor nagyon gyorsan válaszolt a kérdéseimre és kérdéseimre. Még a Storybook támogatást is összevonta, miután lövést adtam rá.

Következtetés: kicsi, de gazdag közösségek

Mindkét technológiát több projektben használják a gyártás során, így már biztonságosan használhatók. A közösségek aktívan és kezdőbarátan fejlődnek.

Ha csapatot kell építenie, ne várjon olyan szabadúszókat, akik pontosan ismerik ezeket a technológiákat, túl specifikusak. Ehelyett összpontosítson olyan teljes JavaScript-fejlesztők felkutatására, akik képesek lesznek gyorsan megtanulni őket. Alternatív megoldásként felkeresheti a forrást, és igazi szakembereket találhat a Vulcan vagy az AUSK közösségek között.

# 5 Telepítés

Nem sok összehasonlítás, mindkét keretrendszer lehetővé teszi a telepítést olyan ingyenes szolgáltatásokat kínáló platformokon, mint a Zeit Now és a Heroku, valamint telepítést a saját egyéni szerverén.

# 6 Kód méretezhetőség és moduláris minták

Vulcan: ossza meg erőfeszítéseit

A keretrendszer egyik előnye az erőfeszítések megosztása. A végfelhasználás egyértelműbb, és így lehetővé teszi számunkra a különböző optimalizálások integrálását magába a keretbe.

A Vulcan olyan mintákat kínál, mint a visszahívások / kampások, fejlesztések és központi regisztráció, hogy teljes mértékben kihasználhassa csomagorientált architektúráját. Például hozzá tudjuk adni a Material UI alkalmazást egy alkalmazáshoz, beleértve az SSR-t is, anélkül, hogy egyetlen kódsort is megváltoztatnánk a Vulcan Core modulban.

Pontosabban, a Vulcan registeraz egyes adatstruktúrákhoz különböző módszereket biztosít, például registerComponentvisszahívásokat, és visszahívásokat is, router.wrapperamelyek lehetővé teszik a AppReact gyökér összetevő bepakolását. Csak egyszer kell importálnia a fájlt a csomagbejegyzés szintjén ( mainfájlok).

AUSK: indulj el a helyes úton, végezd el egyedül

A moduláris architektúra korlátozza a spagetti kódírás kísértését. Kedvezi a kódok újrafelhasználását az alkalmazások között. Minden csomag rendelkezik egy index.tsfájllal, amely deklarálja a többi modullal megosztott releváns köztes fájlokat, indítási függvényeket, graphQL függvényeket.

A jól megnevezett modulemodul osztályokat biztosít minden környezet számára, hogy regisztráljon egy új modult, például ServerModuleés ClientModule. Ez az egyetlen modul, amelyet ténylegesen közvetlenül az alkalmazás szintjén használnak.

 export default new ServerModule({ onAppCreate: [ callback1, callback2] }) 

Belsőleg az összes modul egy nagy modulba kerül, amelyet végül az alkalmazás létrehozására használnak fel. Például az összes onAppCreatevisszahívás egymás után fut.

Ez viszonylag tiszta minta és nagyon okos architektúra. Úgy értem, még a modulkezelő is modul, nem szép?

De a többi rajtad múlik. Szép, mindent optimalizálni tudsz! Szóval elveszíted a GraphQL felbontókat és a Mongo adatbázisodat? Mely eszközök használatával? Hogyan konvertálhatja GraphQL sémáját Mongo vetületekké? Összekötőket fog írni, a DataLoadert használni?

Itt van a lényeg: skálázható alkalmazás megírása nehéz. Nagyon nehéz. Ha tanulni akarsz, akkor jó neked. Nagyon örülök, hogy éppen ezért használom az AUSK-t, a saját maga elvégzése a legjobb módszer a tanuláshoz.

Következtetés: kockázatkerül?

Az AUSK és a Vulcan számára is a kód méretezhetősége moduláris architektúrát jelent. Amikor a kód túl bonyolultá vagy olvashatatlanná válik, a megoldás egyszerű: vágja kisebb, egyszerűbb darabokra.

A vulkáni architektúra merészebb, minden moduláris lehet. Ez az ambíció kockázatot jelent, néha nehéz lehet megérteni, ki mit és mikor regisztrált.

Az AUSK moduláris minták könnyebben olvashatók, de kissé kevésbé hatékonyak is. Például nehéz lehet összetett globális szolgáltatásokat hozzáadni az alapvető csomagkód megérintése nélkül. Mégis mindenképpen elegendőek a legtöbb felhasználási esethez, nem kell modularitásnak lennie ahhoz, hogy jó alkalmazásokat írjon.

# 6 Mobil

Vulkán: Cordovával

A Meteor, amelyre a Vulcan épül, beágyazza Cordovát. Tehát a webalkalmazás mobilalkalmazásként csomagolható egyetlen parancssorral.

A Vulcan azonban nem nyújt eszközöket a natív alkalmazásokhoz. Természetesen továbbra is létrehozhat egy független React Native alkalmazást, és csatlakoztathatja a Vulcan-hez. Az elkövetkező hónapokban a hitelesítési rendszer (jelenleg a Vulcan utolsó darabja valóban a Meteorra támaszkodik) fejlesztését tervezik az ilyen kapcsolatok megkönnyítésére.

AUSK: React Native-val

A „vanília” React és a React Native beállításainak kombinálása az AUSK egyik legjobb tulajdonsága. Végül is ez egy univerzális kezdőkészlet! Magam nem nagyon mobilozok, de megnyugtató, hogy gyorsan létrehozhatok egy natív mobilalkalmazást, amely ugyanazt a szervert osztja meg, mint a webes felületem.

Következtetés: Az AUSK jobb a mobilban

Az AUSK jobban megfelel, ha kifejezetten mobilalkalmazást kell írnia. Mindazonáltal a Vulcan lehetővé teszi mobilalkalmazás építését a kódból egyetlen parancssorban, ami rendben van, ha a mobil verzió másodlagosabb számodra.

# 7 A felhasználói felület módosítása: nehéz kérdés

A fullstack keretrendszer létrehozása, amely lehetővé teszi az UI könyvtár azonnali megváltoztatását, csak a CSS korszakában érhető el. Emlékszel azokra a webhelyekre, amelyek lehetővé tették a téma váltását egyetlen gombra kattintva?

Aztán a JS nemzetek támadtak. A React komponensek használatával nagyon nehéz ilyen funkciót biztosítani (kivéve a triviális színváltozásokat), mert a stílus és a design most nagyon kötődik az alapul szolgáló React / Angular / Vue komponensekhez.

Minden React UI libnek megvan a maga módja egy gomb definiálására, anélkül, hogy ezekről is beszélne. Ez problémát jelent az olyan full stack technológiáknál, mint az AUSK és a Vulcan, mert a stíluskeret kiválasztása ízlés kérdése. Nem csak egy végleges választást javasolhatnak és arra kényszeríthetik, hogy ragaszkodjon ehhez. A Bootstrap már nincs monopóliumban, és minden fejlesztőnek megvan a maga kedvenc libje.

E probléma megoldása érdekében mindkettő hasonló megközelítést alkalmaz. Írtak egy kanonikus alkatrészkészletet a Bootstrap-tal, majd megpróbálták lehetővé tenni ezen alkatrészek cseréjét egy másik lib-re, mint az Ant Design vagy az Material UI.

Furcsává teszi a kódot. Például az AUSK gomb vesz egy kelléket color, mert a Bootstrap így működik. Ha az Ant Design-ra vált, akkor a színes támaszt is használnia kell, még akkor is, ha az Ant Design typetámaszt használ helyettük.

Mivel a felhasználói felület keretrendszerének kiválasztása általában csak egyszer történik meg, a fejlesztések során nem kanonikus kellékkészlet használatának kötelezettsége az összes fejlesztés során nagyon magas árnak tűnik a több felhasználói felület keretrendszerének támogatásáért.

A fejlesztés során azt javaslom, hogy amennyire csak lehetséges, kerülje ezeket az előre kódolt összetevőket az egyedi felhasználói felülethez. Nagyszerű felépíteni a kazán / keretrendszer által nyújtott példát és általános szolgáltatásokat, de nem annyira, ha az alkalmazás egyedi részeit kell megírni.

Ehelyett használja az Ant Design, a Bootstrap vagy a Material UI által biztosított mögöttes összetevőket, a választásától függően, és próbálja meg megírni a saját UI libjét. A folyamatban segítséget nyújthat a Storybook fizetéséhez, mivel mind az AUSK, mind a Vulcan tartalmazza.

# 8 INGYENES harc

Ha megtartanám az egyes technológiákra jellemző megkülönböztető jellemzőket, akkor ezek lennének.

Vulkán

A séma rendszer. Legjobb tudomásom szerint egyetlen keretrendszer sem képes egyetlen JSON-sémából létrehozni az adatbázis-struktúrát, a kiszolgáló belépési pontjait, az ügyfél / szerver kommunikációs réteget és a gyártásra kész kezelőfelületet (űrlapok, listák stb.).

A Vulcan.js ezt megteheti a legújabb JS technológiák használata közben.

AUSK

Nem sikerült csak egyet kiválasztanom, ezért az AUSK szeretett tulajdonságai a TypeScript és a React Native lesznek.

Néhány éve viták folynak a statikusan gépelt JavaScript előnyeiről, hogy inkább a Flow-t vagy a TypeScript-t részesítsék előnyben ... És a TypeScript mindenképpen megnyerte a harcot. A TypeScript használata a Vulcan-ban lehetséges, de a Meteor használata miatt jelenleg természetellenesnek tűnik, és az összeállítás lassú. Az AUSK alapértelmezés szerint a TypeScript-t használja, és ez fantasztikus.

És a React Native ... nos, vannak ilyenek isvitatja, hogy a React használata mobilalkalmazások megírásához releváns-e. Dönthet úgy, hogy ragaszkodik egy adaptív webalkalmazáshoz, de legalább tudja, hogy minden beállítva van, tekintve, hogy a dev env beállítása a React Native számára nem mindig könnyű feladat.

Tehát választottál?

Olyan sok szempontot kell figyelembe venni, mint a teljesítmény, a biztonság, a DevOps, a hitelesítés-kezelés ... A megfelelő eszköz kiválasztása a JavaScript alkalmazás elkészítéséhez természetesen nem könnyű választás. Remélem, hogy ez a cikk értékes betekintést adott a döntéshez.

Ha még mindig habozik, keressen meg Vulcan's Slack-en, örömmel válaszolok nekik :)

Bármely kérdést irányíthat az AUSK-on Victor Vlasenkóhoz és a SysGears csapatához, és csatlakozhat a Vulcan dedikált Slackjéhez, hogy hozzáférjen a Vulcan közösséghez.

Utolsó tanácsom ilyen egyszerű lesz: adjon egy lövést mind a Vulcan-nak, mind az AUSK-nak, megéri az idejét!

Köszönet Sacha Greifnek és Victor Vlasenkónak a cikk áttekintéséért.

LBKE banner twitter

Társalapítója vagyok a francia Lebrun Burel Knowledge Engineering (LBKE) vállalatnak - //www.lbke.fr

Mindig örömmel beszélek a kódról, a gépi tanulásról, az innovációról és a vállalkozói szellemről!