Frontend fejlesztésnél, főleg ha egy frameworkre építünk, mint az Angular, Vue vagy Svelte, gyakran felmerül, hogy mikor éri meg külső, 3rd party libraryt behúzni a projektbe. Sokan azt hiszik, hogy ezek a libraryk ingyen funkcionalitást adnak, amit nem kell magunknak megírni. Pedig a valóságban minden librarynek van költsége, és alaposan át kell gondolni, mit nyerünk és mit veszíthetünk vele. Az alábbiakban összefoglalom, hogyan döntök a libraryk használatáról, milyen szempontokat nézek, és hogyan kezelem a hosszú távú kihívásokat.

Mikor van értelme külső libraryt használni?

Első körben azt nézem, mennyi idő lenne a kívánt funkcionalitást nulláról lefejleszteni. Ehhez hozzácsapom a projekt jellegét, a várható jövőbeli igényeket és a csapattagok tudását. Ha a funkció gyorsan megírható, nem húzok be külső libraryt. Minek bonyolítsam a projektet egy új függőséggel, ha egyszerűbb saját kézzel megoldani?

Ha a fejlesztési idő közepes vagy hosszabb, akkor már más is számít. Például azt mérlegelem, hogy a funkció fejlesztése során megszerzett tudás mennyire lesz hasznos később. Ha egy üzletileg fontos komponensről van szó, amelynek ismerete segít a rendszer átlátásában vagy bővítésében, akkor inkább házon belül fejlesztem. Egy ügyviteli projektben viszont, ahol mondjuk egy látványos, "eye-candy" komponens kell csak, nem biztos, hogy megéri a tudást bent tartani, mert az nem hoz hosszú távú hasznot. Ilyenkor inkább külső libraryhez nyúlok.

Komolyabb vagy időigényes feladatoknál nagy eséllyel eleve külső libraryn gondolkodom. Például, ha egy projektben földterületek méretét kell kiszámolni, ami üzletileg kulcsfontosságú, de matekban és térgeometriában nem triviális, nem kezdenék saját megoldásba. Egy ilyen speciális területen a külső library időt és energiát spórol, még akkor is, ha a tudás bent tartása elméletileg hasznos lenne.

A libraryk költségei

Nem szabad elfelejteni, hogy a libraryknek mindig van költsége. Először is, időt kell rászánni, hogy megtanuljuk a használatukat. Néha egy library olyan nagy és bonyolult, hogy gyorsabb megírni a funkcionalitást magunknak, mint kitanulni. Máskor egyszerűbb megírni, mint egyáltalán telepíteni. Ráadásul a libraryk változásai, például új verziók vagy breaking change-ek, átírást igényelhetnek a saját kódunkban, ami szintén idő és energia.

Hogyan válasszunk jó libraryt?

A library kiválasztásakor több dolgot megnézek, hogy biztos legyek a megbízhatóságban, a karbantarthatóságban és a hosszú távú illeszkedésben. Először is, azt nézem, mennyire szükséges karbantartani. Ha például külső rendszerekhez csatlakozik, más librarykre épül, vagy olyan alapokra támaszkodik, amelyek hajlamosak biztonsági hibákra (mondjuk regex), akkor van rá esély, hogy gyakran kell frissíteni. Ha a karbantartók nem tudják ezt követni, az gondot okozhat. Viszont ha a library "kész" van, vagyis tökéletesen megcsinálja, amit kell, és nincs szükség további fejlesztésre, akkor akár egy többéves verzió is jó lehet.

A megbízhatóság szempontjából fontos, hogy a library forráskód-követő rendszerében (például GitHubon) milyen a nyitott és lezárt hibajelentések aránya a kód terjedelméhez és bonyolultságához képest, és hogy van-e rendes tesztlefedettség. Az is számít, hányan gondolják jónak a libraryt, például a GitHub "star"-ok vagy az npm letöltések száma alapján. Emellett ellenőrzöm, hogy a legfrissebb verzióban van-e nyitott biztonsági hiba (például a CVE adatbázis vagy npm audit alapján), és hogy a projekt tudja-e egyáltalán használni a legfrissebb verziót. Ha nem, akkor azt is megnézem, hogy vannak-e backportolt biztonsági javítások a régebbi verziókhoz. Ha amúgy minden rendben, akkor a múltbéli reakciók is beszédesek lehetnek: mennyi idő alatt és milyen alapossággal javítják a felfedezett hibákat.

A közösségi támogatás is lényeges. Nem elég, hogy sokan használják; az is fontos, hogy a közösség mennyire aktív a fejlesztésben. Ha csak egy ember dolgozik rajta, az kockázatos, mert ha ő kiesik, megállhat a projekt. A legjobb, ha legalább 2-3 olyan fejlesztő van, akik nagyjából egyformán sokat tesznek hozzá, és megosztják a tulajdonosi jogosultságokat, így a library akkor is életképes marad, ha valaki lelép.

A dokumentáció sem elhanyagolható. Ezt több oldalról is megnézem: van-e például a kódkiegészítésnél függvényleírás, használati példa, vagy tipikus hibák és azok elkerülésének leírása? Van-e egy "kézikönyv" jellegű dokumentáció, ami kereshető, példákkal szemléltetett, és jól formázott? Ezek rengeteget segítenek a fejlesztés során.

A library mérete is számít. Ha csak a funkciók töredékét használom, de a bundle méretét jelentősen megnöveli (például 1% funkcionalitás 25% méretnövekedést okoz), akkor elgondolkodom alternatívákon vagy más megközelítésen. Például lehet, hogy a releváns kódrészletet gond nélkül beemelem a projektbe. Ezzel elveszítek pár előnyt (frissítések, közösségi támogatás), de nem terhelem a felhasználókat olyan kompromisszumokkal, amire nincs szükségük (legyen az akár méretbeli, teljesítmény vagy akár memóriahasználat okán).

A kiválasztásnál azt is nézem, hogy a library mennyire illeszkedik a választott frameworkhöz. Angular esetén például nagy előny, ha van típusdefiníció, mert ez segít a fejlesztésben és a kód megértésében. Ha a library Angular modulon keresztül használható, vagy az Angularban elterjedt reaktív mintákat követi, az még jobb. Az sem mindegy, hogy unit tesztelésnél jól mockolható-e, esetleg eleve ad-e mock változatot.

Mi van, ha a library elavul?

Ha a library elavul vagy a karbantartása leáll, több megoldásom is van. Ha még mindig használható a projekt igényei szerint, egyszerűen forkolom, és a saját csomagkezelőmből használom tovább. Ha már nem jó, akkor számolok azzal, hogy valószínűleg van alternatíva. A migráció időigényes lehet, de tervezhető. Éppen ezért érdemes a libraryt egy belső absztrakciós rétegen keresztül használni, ami csökkenti a csere munkáját. Ha gyors tűzoltás kell, a funkcionalitást átmenetileg saját kézbe veszem (fork + saját csomagkezelő), míg az alternatívára váltás egy lassabb, tervezett folyamat keretében zajlik.

Absztrakciós réteg a rugalmasságért

A külső libraryk gyakran többet tudnak, mint amire a projektben szükség van. Ezért először mindig azt nézem, mire van szükségem, és hogyan illeszthető be az üzleti logika már meglévő mintáiba. A libraryk ritkán passzolnak tökéletesen, ezért egy "lebutított", testreszabott absztrakciós réteget építek köréjük. Ez csak azokat a funkciókat adja, amik kellenek, és úgy, hogy illeszkedjen a projekt struktúrájához. Így, ha később egy kevésbé fejlett libraryre kell váltani, de az a szükséges funkciók nagy részét lefedi, a csere nem okoz nagy gondot.

Licencelés és jogi kérdések

Fontos megnézni, hogy a library milyen licenccel rendelkezik. Ha például egy MIT vagy Apache licencű libraryről van szó, az általában gond nélkül használható a legtöbb projektben. De ha egy szigorúbb, például GPL licencű libraryt nézek, az megkötheti a kezem, mert előírhatja, hogy a saját kódomat is nyílt forráskódúvá kell tennem. Ez üzleti projekteknél nagy gond lehet. Azt is érdemes ellenőrizni, hogy a licenc kompatibilis-e a projekt többi részével, nehogy később jogi problémák jöjjenek elő.

Röviden a mérlegelendő szempontokról

Élettel teli: karbantartott? fejlesztett? utolsó commit? utolsó release? heti letöltések? fő fejlesztők száma?

Biztonságos: CVE? npm audit? backportolt javítások? múltbéli reakciók?

Minőségi: tesztlefedettség? hibajelentések? dokumentáció? közösségi támogatás?

Hatékony: teljesíti a célt? csak a szükséges funkciók? méret? teljesítmény?

Kompatibilis: illeszkedik a frameworkhöz? típusdefiníció? mockolhatóság?

Összegzés

A 3rd party libraryk használata frontend projektekben nem ördögtől való, de alaposan át kell gondolni. A fejlesztési idő, a csapaton belüli tudás értéke, a library megbízhatósága, karbantarthatósága, dokumentációja, licenszelése, mérete, a frameworkhöz való illeszkedése, elterjedtsége, stabilitása és használhatósága mind fontos szempont. Az absztrakciós réteg és az elavulásra felkészült stratégiák pedig biztosítják, hogy a projekt stabil és rugalmas maradjon. Egy jól megválasztott library időt spórol, miközben a fejlesztés fókusza az üzleti logikán maradhat. Viszont sose felejtsük el: minden librarynek van költsége, és csak akkor használjuk, ha a haszna tényleg meghaladja ezt.