Pár gondolat arról, hogy miért kezdtünk el Rust-ot használni webes fejlesztésekhez
Többen kérdezték már tőlem, hogy miért használunk Rust-ot webes alkalmazás fejlesztésére.
Kicsit ágyúval verébre megoldás, hiszen vannak sokkal egyszerűbb alternatívák is. Dinamikus programozási nyelvek kedvelőinek ott a PHP, a Python vagy a Node.js, szigorúan típusos nyelvek kedvelőinek a Java, a C# vagy a Go.
Régebben a legtöbb webes feladatra PHP-t használtunk. A backend fejlesztőink szerették, de a frontend fejlesztők már nem annyira: gyakran kellett kevert kódot szerkeszteniük, ahol a saját jól ismert technológiáik mellett valamilyen template nyelvet vagy a PHP-t is ismerniük kellett kicsit. Ráadásul sok volt számukra a mágia: amikor valamilyen backendes megoldás generált ki egy nagyobb szelet frontend kódot, abba nehezen tudtak belenyúlni.
Részben emiatt, részben a mobil alkalmazások elterjedése miatt a fejlesztés eltolódott abba az irányba hogy a backend-en csak egy API-t fejlesztünk a megjelenítést pedig teljesen a frontendesekre bízzuk. Ők döntik el hogy single page web application születik vagy node.js-es server side rendering-et használunk.
Van néhány olyan ügyfelünk ahol elég nagy forgalmat kell kiszolgálnunk és bizony azt tapasztaltuk hogy a node.js alapú server side rendering a PHP-hez hasonlóan elég lassú tud lenni. Ezért a server side rendering mindig csak az oldalak statikus alapváltozatát generálja ki, soha nem jelenít meg az aktuális felhasználótól függő tartalmat. Így a kigenerált oldalak jól cache-elhetővé váltak, azokat elég néhány másodpercenként vagy néhány percenként egyszer legenerálni.
A backend oldalon eleinte maradtunk a PHP-nál, de arra jöttünk rá hogy API-k fejlesztéséhez igazából nem előnyös egy dinamikus programozási nyelv. Egy statikusan típusos programozási nyelv esetén a kérések és válaszok sémája a legtöbb esetben automatikusan generálható az adatmodelből. Ez PHP-ból is megoldható de csak akkor ha mindenhol figyelünk a típus deklarációk megadására, akkor meg már majdnem ugyanott vagyunk mintha egy szigorúan típusos nyelvet használnánk. Ráadásul a statikus programozási nyelvek teljesítménye általában jobb mint a dinamikus nyelvek teljesítménye, emiatt teljesítmény okokból is célszerűnek látszott ebbe az irányba mozdulni.
Eleinte elsősorban a Go programozási nyelv felé fordultunk. Nem tökéletes, de egyszerűbb feladatokra bevált, fejleszteni ugyanolyan hatékonyan tudtunk vele mint a PHP-val, a teljesítménye pedig sokkal jobb. Az utóbbi időben a C#, .NET világ felé is tettünk lépéseket, ami az elmúlt pár évben jól használhatóvá vált Linux alatt is. Régebben tettünk pár kísérletet a Java-val is, de mióta az Oracle rátette a kezét azóta kevésbé tűnik vonzó alternatívának. A Rust-ot kezdetben elvetettük, mert elég rémisztő sztorikat olvastunk a komplexitásáról.
Aztán néhány éve, amikor egy különösen teljesítményigényes feladatra kerestünk megoldást, újra elővettük a Rust-ot és megnéztük alaposabban.
A Go-nak, a C#-nak illetve a Java-nak ugyanis teljesítmény szempontból van egy közös problémája, ez pedig a garbage collector. Mindhárom nyelv futtató környezete sokkal több memóriát használ mint amennyire feltétlenül szüksége lenne, ráadásul amikor sor kerül a memória takarítására az kicsit meg is tudja akasztani az alkalmazás működését. A Rust-ban nincs garbage collector így reménykedtünk benne hogy jóval kevesebb memóriát fog fogyasztani mint a Go.
A Rust megértése tényleg nem könnyű, a mai napig sok olyan helyzetbe futunk ahol igencsak fel tudja adni a leckét. Viszont meglepődve tapasztaltuk hogy néhány hét betanulás után a legtöbb feladatot könnyen meg tudtuk oldani vele, nem volt számottevően lassabb a fejlesztés mint mondjuk a Go-val. Cserébe viszont olyan teljesítményt és olyan alacsony memóriahasználatot kaptunk, amit korábban nem igazán tapasztaltunk. Az sem hátrány hogy a nyelv hatékonyan támogatja a biztonságos programozást. A makrónyelve nagyon sok repetitív feladatot le tud egyszerűsíteni, típusrendszere is jól használható, rugalmas.
Ha belegondolunk hogy egy nagyobb cloud alapú rendszerben mekkora részt tesz ki a költségekből a memóriaigény, elég jól látszik hogy a Rust használatával jókora megtakarításokat lehet elérni. Persze minden esetben mérlegelést igényel hogy a várható megtakarítás mennyi idő alatt hozza vissza a fejlesztésre fordított összeget.
Hiányosságok azért még vannak. A nyelv fiatal, ezért jóval kevesebb kiforrott eszköz áll hozzá rendelkezésre mint mondjuk a C# -hoz. Ha mondjuk egy SOAP API-val kellene kommunikálni, valószínűleg nem Rust-ban fognék hozzá, azt C# -ból sokkal egyszerűbb megoldani. Aztán lehet hogy a C# csak egy vékony adapter réteg lenne a SOAP-os backend és a Rust-os alkalmazás között, de ezt már az adott feladat döntené el.
Szintén probléma, hogy Rust fejlesztőt találni egyelőre még nem igazán lehet. Inkább magunk képezzük át a backend fejlesztőinket más programozási nyelvekről.
Összességében nekünk pozitív tapasztalataink vannak a Rust-tal és új projecteknél mindig számításba vesszük ezt az opciót is. Természetesen ez nem jelenti azt hogy mostantól minden backend API-t Rust-ban fogunk írni. Erősen feladat függő hogy megéri-e használni.