Skálázhatóság a Flutter projektekben
Tervezz hosszú távra!

Flutter projekt skálázhatóság és nehézségei
Gyakori kódbázis képe

A sikeres digitális termékek építése nem csak a mostani eredményekről szól, hanem a jövőre is gondol. Egy skálázható és jól karbantartható megoldás nem csak jelentős költségmegtakarítást eredményez a cég számára hosszú távon, de a fejlesztők motivációját és megelégedettségét is növeli. Érdekes módon, ha egy fejlesztő átvesz egy projektet, és azt jól strukturáltan találja, kevésbé kísérti a kód újraírásának gondolata. Ebben a bejegyzésben bemutatom, milyen technikai szempontokra érdemes odafigyelni.

Mitől lesz egy projekt skálázható?

A mai posztban ezekre a kérdésekre keressük a választ: skálázhatóság és hogyan kezeljük okosan a függőségeket? Miért fontos mindez nem csak a fejlesztők, hanem a cégvezetők számára is? Kitérünk a pubspec.yaml fájl finomságaira, a monorepo előnyeire és buktatóira, valamint megvizsgáljuk, hogyan segíthetnek a saját package-ek.

Skálázhatóság alatt a rendszer képességét értjük arra, hogy megnövekedett terhelés mellett is megfelelően működjön. Nem csak a felhasználói szám növekedése okozhat terhelést, hanem például egy vállalat üzleti növekedése is.

Egy skálázható mobilapp rugalmas, és lehetővé teszi a kód könnyű karbantartását és fejlesztését.

Miért fontos ez?

Mert a skálázható rendszerek költséghatékonyak és időt takarítanak meg a jövőben. Nem csak a fejlesztők, hanem az egész vállalat számára.

Egy skálázható rendszer nem csak költségeket és időt takarít meg, hanem a fejlesztői csapat motivációját is növeli.

Amikor egy csapat egy jól szervezett, skálázható kódbázison dolgozik, a code-review-k gyakorisága és a refaktorálások szükségessége is csökken. Emiatt a fejlesztők több időt tölthetnek a valódi problémamegoldással és az innovációval, ami általában magasabb munkamorált és jobb termelékenységet eredményez.

Függőségkezelés: a pubspec.yaml alapjai

A pubspec.yaml egy Flutter projekt lelke. Nem csak egy sima konfigurációs fájl, hanem az alkalmazásod ‘központi irányítója’. Itt határozhatsz meg függőségeket, vagyis kódcsomagokat és könyvtárakat, amelyek az alkalmazás működéséhez szükségesek.

Ezáltal megkönnyíti az egész csapat munkáját és egy helyen van összegyűjtve minden, ami az app működéséhez kell.

Emellett lehetőséget biztosít az Open Source közösség megoldásainak újra felhasználására. Ezzel időt és erőforrást takarítunk meg. A függőségkezelés így kulcsfontosságú a skálázhatóság és a fejlesztési idő optimalizálása szempontjából.

A monorepo előnyei és kihívásai

A monorepo, vagyis egyetlen kódtárba szervezett projektstruktúra előnyöket és kihívásokat is rejt. A monorepo önmagában nem egy különleges Git repozitori, hanem a benne lévő tartalom szervezési módja teszi azzá.

Előnyei közé tartozik az egységes verziókezelés, a közös függőségek könnyebb kezelése és a csapatmunka megkönnyítése. Egy ilyen rendszerben könnyebben nyomon követhetők a változások és egyszerűbben menedzselhetők a projekten belüli függőségek.

Ugyanakkor a monoreponak kihívásai is vannak: megfelelő infrastruktúra és eszközök nélkül könnyen kezelhetetlenné válhat. Különösen fontos itt a függőségkezelés, hiszen egy rosszul kezelt monorepo gyorsan kaotikussá válhat.

A monorepo kaotikussá válhat, ha nincs jól szervezett függőségkezelés és verziókövetés. Ha több projekt vagy modul egymástól függ, és nincs megfelelően kezelve ezek kapcsolata, akkor a kódbázis könnyen instabillá válhat.

Egy nagy csapat esetében az egyes tagok változtatásai könnyen “összeütközhetnek”, ami hibákat és felesleges munkát generál. Ezért a kódminőség ellenőrzése, például code-review és tesztelés, kritikus jelentőségű egy monorepo esetében.

Saját Package-ek: a karbantarthatóság és skálázhatóság eszközei

A saját package-ek létrehozása segít modularizálni az alkalmazást. Ez lehetővé teszi a kód újrafelhasználását és a fejlesztői csapatok közötti együttműködést. A saját package-ek azért is jók, mert lehetővé teszik az alkalmazás egyes részeinek izolált fejlesztését és tesztelését. Ennek következtében a kód karbantarthatóbb és könnyen skálázható lesz.

Még jobb, ha ezek a package-ek Open Source közösséggel is megoszthatóak, ami további elismerést és visszajelzést generál. Nem beszélve az “ingyen” javításokról.

Leggyakoribb a domain-alapú szervezés. Ez lehetővé teszi a csapatok számára, hogy külön felelősségi körökre koncentráljanak. Ez nemcsak a fejlesztési időt csökkenti, hanem a kód minőségét is javítja, mivel minden csapat mélyebb szakértelmet fejleszthet ki a saját domainjében.

Ez az elképzelés tökéletesen illeszkedik a mikroszolgáltatásokhoz hasonló architektúrákhoz és a nagyobb, összetett rendszerekhez.

A modularizálásnál általában a következő szempontok alapján szokták az alkalmazást package-ekbe szervezni:

  1. Biztonságért felelős modul: Autentikáció, titkosítás, és jogosultság-kezelés.
  2. Hálózati Kommunikáció: API hívások, WebSocket kommunikáció.
  3. Domain Logika: Üzleti logika, adatmodellek, és adatmanipulációs metódusok.
  4. UI/UX Komponensek: Újrafelhasználható widgetek, stílusok, reszponzív design.
  5. Adattárolás: Lokális adatbázis kezelés, cache.
  6. Közös Funkcionalitás: Navigáció, állapotkezelés.
  7. Fizetési megoldások: Tranzakciók, online vásárlások, és kapcsolódó biztonsági intézkedések.

A fő cél itt a szorosan összefüggő funkciók csoportosítása és azok elkülönítése. Ezek különböző fejlesztési fázisokban vagy csapatok által lehetnek kezelve. Ezzel könnyebbé válik a karbantartás és a skálázás.

Összefoglalás

A skálázhatóság nem csupán technikai, de üzleti előnyöket is hoz.

Egy jól skálázható rendszer csökkenti a fejlesztési és karbantartási költségeket, növeli a fejlesztői csapat motivációját, és biztosítja a jövőbeni rugalmasságot. A monorepo struktúra és a modularizált kódbázis segíthetnek ebben.

A központi csomagkezelő (pubspec.yaml file) pedig lehetővé teszi, hogy könnyen integráljuk a már létező, kipróbált megoldásokat, időt és erőforrást spórolva.

Összességében, a skálázhatóság nem csupán a fejlesztők, hanem a cégvezetők számára is kulcsfontosságú.

A Flutter eszköztára rendkívül sokoldalú és hatékony, így skálázható és karbantartható alkalmazások fejlesztéséhez kiváló választás.

További írásaim is érdekelhetnek:

Weboldal a mobil app helyett
Van olcsóbb megoldás mobilra

Weboldal vagy mobil UI tervezés termékfejlesztés közben
Forrás: Unsplash, amayli

Biztosan te is jártál már úgy, hogy rengeteg ötletet összeírtál magadnak. Ezek közül végre sikerült kiválasztani a kedvencedet. Rászántad az idődet, hogy utánanézz, lekutasd a témát. Ilyet még senki sem csinált! Remek! – gondoltad magadban. Már csak meg kell valósítani. De hogyan? Weboldal legyen vagy mobil alkalmazás? Netán PWA? Ez azonban csak a kezdet. Számos más kérdést kell még feltenned magadnak.

Ötletem már van. Hogyan lesz ebből bármi is?

Ha még nem találkoztál digitális termék fejlesztésével, akkor ajánlom körbejárni a témát. Az Így tervezz mobil alkalmazást 5 lépésben – 1. rész kendőzetlenül körbejárja a téma. Ezért most nem írom le részletesen, bővebben ott olvashatsz róla.

Hol induljak el vele?

Hogyhogy hol?? Az interneten, nem?” – Nos, nem ilyen egyszerű! 🙂

Volt szerencsém beszélgetni pár ötletgazdával. Ezek az alkalmak kiválóak arra, hogy pár kérdést a helyére tegyünk. Olyan szempontok merülnek fel, amik nem jutottak eszébe az ötletgazdának. Ez nem gond, hiszen azért osztja meg velem, hogy hozzáértően, konstruktív kritikát fogalmazzunk meg együtt.

Én csak egy mobil appot szeretnék, ami ezt meg azt csinál. – mondja Feri
– Értem. Tehát lesznek felhasználóid, beléptetéssel, igaz? – kérdezem
Aha! – vágja rá
– Social login is lesz? – teszem fel. – Tudod, Google, Facebook, stb.
Erre nem is gondoltam. – vallja be
– Kelleni fog majd egy szerver is. – vetem fel
Az meg minek? – kételkedik
– Tudod, a fizetési tranzakciókat hol fogod látni? Mi van, ha probléma merül fel?
Egy admin oldalra gondolsz? – csillan fel a szeme
– Igen. Neked fizető ügyfeleid lesznek, akiknek lesznek problémái. – erősítem meg

A fenti párbeszéd persze a képzelet szüleménye. Bár hasonlók szoktak elhangozni.

További szempontok, amiket érdemes megválaszolnod magadnak:

  1. Ha mobil app, akkor Android és iOS-re ki kell adni a store-okban.
  2. Kb. fél évente érdemes őket frissíteni. Ez fontos ASO (App Store Optimization, kb. ugyan az, mint a SEO) szempontból.
  3. Szükséged lesz fejlesztői fiókra, ahol kiadhatod (Owner, Account Holder)
  4. Kelleni fog valaki, aki megtervezi a kinézetet (design).
  5. Szerver (web)alkalmazás elengedhetetlen lesz a felhasználók, termékek, beállítások kezelésére. Cloud, VPS, mi legyen?
  6. Kell egy rövid, jól csengő név, logó. Apropó, domain regisztráció.
  7. Weboldal, ahol ismertető, Blog, GDPR, Adatkezelési szabályzat stb. elhelyezhető.
  8. Nem mindenki szereti a mobil alkalmazást. Biztosan erre van szükséged? Hallottál már a PWA-ról?
  9. A sok funkcióból szűrd ki, mi lenne az, amit legelőször szeretnél bemutatni? A többit hagyd későbbre!

Mennyi az annyi?

Konkrétumokban nem lehet beszélni erről. Ahány elképzelés, annyi féle kombináció. Azonban ökölszabályokat lehet hozni.

Tudnod kell, hogy egy mobil fejlesztés több lépésből áll, mint egy weblap kialakítása. Emiatt az árak is markánsabbak. A néhány száztól a több ezer munkaóráig terjedhet egy kis-közepes termék kialakítása. Vannak nem megúszható részek. De néhány párhuzamosítható, vagy későbbre tolható. Innen pedig egyszerű a matek, mert az óraszámot fel kell szorozni a fejlesztői órabérekkel.

Az egész az alábbi nagy fázisokban határozható meg:

  1. Ötlet gyűjtés
    • Kinek?
    • Mit?
    • Fizetős vagy Ingyenes?
  2. Termék meghatározása
    • Funkciók
    • Mi lenne, ha… ?
    • Iparági szabványok felkutatása
  3. Prototípus(ok) kialakítása
    • Rajzok, Mock-up-ok
    • felhasználói interjúk
    • design tervezetek (Figma, Adobe XD)
    • MVP
  4. Fejlesztés
    • felhasználói visszajelzések alapján
    • design véglegesítése
    • kódolás
    • mobil app, szerver, weblap, automatizálás, fizetési szolgáltató integrálása
  5. Tesztelés
    • fejlesztői tesztek (unit, integrációs)
    • automata tesztek
    • végfelhasználói tesztek (end-to-end, E2E)
    • jegyzőkönyvek, riportok
  6. Bevezetés, értékesítés
    • sales, marketing, PR
    • közösségépítés, kampányok
    • app store-okban kiadás
  7. Utóélet, támogatás
    • ügyfélszolgálat, helpdesk
    • rendszeres javítások
    • (termék visszahívása, kivonása)

Beszélj szakemberrel

Ha ezek borzasztóan hangzanak, beszélj egy szakemberrel.

A fenti tevékenységek közül számos elhagyható, egyszerűsíthető. Nem feltétlenül kell mindent megcsinálni. Nem is lenne reális kisebb ötleteknél.

Éppen ezért nem árt, ha nem egyedül vágsz neki. Pár alkalmas tanácsadás, vagy beszélgetés költsége még mindig megfizethető, mielőtt nagy fába vágnád a fejszédet. Kérhetsz ütemezést, hogy a cash-flow rendben legyen.

A jó szakember le tud beszélni egy költséges, vagy bonyolult részről. Akár egy jó alternatív helyettesítő megoldást mutat rá.

Érdemes élni a szakmai kapcsolatainak a kiaknázásával. Megfelelő szolgáltatók, partnerek ajánlásában sokat tud segíteni. Nem neked kell 3-5-10 felé beszélni az adott szakterületen. Persze fel is oszthatóak a feladatok: mindenki azt csinálja, amihez ért.

Kommunikáció

Fontos a projekt közben a tiszta kommunikáció. Ez lehet élőben, video call-on keresztül, emailben. A lényeg, hogy a leghatékonyabb legyen. Mindenki ideje drága. A meeting végére szülessen egy döntés. Ne csak a meeting kedvéért üljünk össze. A felmerülő kérdéseket és az azokra kapott válaszokat rögzítsük egy rendszerben (issue tracker, feladatkezelő, Excel 🙂 ), ahol mindenkinek elérhető.

Haladj a saját ütemedben

  • Ha nincsen meg a tudásod, olvass!
  • Ha nincsen meg a tőkéd, kerítsd elő! Vagy szerezz támogatót! Vagy egy közösséget, aki megelőlegezi neked. Ilyen a www.brancskozosseg.hu.

Lehet, hogy először csak egy fehér A4-es papíron lesz bemutatható. Ezután már lesz egy Figma terved, prototípusod. Aztán jöhet egy reszponzív weboldal, PWA vagy egy böngésző kiegészítő (Firefox, Chrome extension). Ha jó a fejlesztői keretrendszer, akkor abból könnyen lehet készíteni natív appokat. (Ilyen például a legnépszerűbb Flutter mobil app keretrendszer.)

A témában írtam több cikket, ezek is érdekelhetnek:

Ha szeretnél mobil appot fejlesztetni, de nem tudod, hogy hogyan indulnál neki, vagy csak támogatásra van szükséged benne, akkor keress meg a kapcsolataim egyikén.

money from wallet

Legjobb érvek egy mobil-alkalmazás megrendelése mellett
Ezeket ellenőrizd, mielőtt megrendeled

mobil-alkalmazás vagy weblap legyen

Az elmúlt több, mint 10 évben, amikor megjelentek az okos telefonok, egy új formátumot hoztak magukkal: az app-okat. Miben nyújt többet egy mobil-alkalmazás egy responsive weblap helyett? Ha komoly elhatározásunk van egy mobil-alkalmazás megrendelése mellett, akkor az elképzelésünknek már csak a pénztárcánk szabhat határt. Ár-érték arányban hogyan teljesítenek a jól bejáratott weblapokhoz képest? Ezt a témát járom körül.

Mit mutatnak az alkalmazás-áruházak statisztikái

Kezdjük a száraz számokkal, mert azok ritkán tévednek. A statista.com mutatóit megnézve, látható, hogy a mobil-alkalmazások letöltései töretlenek. Évről évre a bővülő készülékszám mellett az app letöltések is bővülnek.

mobil-alkalmazások letöltésének száma világszerte
A mobil-alkalmazások letöltésének száma világszerte 2016 és 2019 között

Az Apple App Store 2020 júniusi kimutatása szerint a letöltések 50%-át a következő kategóriák teszik ki: Játékok (22%), Üzleti (10%), Oktatás (9%), Életmód (9%). Ebből körvonalazódik, hogy melyek a nyerő irányok. A lista végéről nézve érdekes kép rajzolódik ki: Hírek, Orvoslás, Fotó és Videó, Sport, Social Networking, Vásárlás, Zene, stb. Kb. 2-3%-ot jelent minden egyes kategória. Az alacsony részesedés magyarázható azzal, hogy a hírekre ott van a web; fotó és videó, zenelejátszó alapból jár a telefonra, előre telepítve.

Az digitális termékekre költött fogyasztói kiadásokat mutatja az alábbi grafikon. Ha az EMEA régiót nézzük (Europe, Middle-East, Africa), akkor az előre vetített bővülés több, mint 150%-os 2018-ról 2022-re.

mobil-alkalmazásokra vonatkozó fogyasztói költések világszerte
A mobil-alkalmazásokra vonatkozó fogyasztói kiadások világszerte 2017-ben, 2018-ban és 2022-ben, régiónként, milliárd USD-ben.

2018-ban a globális mobilalkalmazások bevétele több mint 365 milliárd USD volt. 2023-ban a mobil alkalmazások várhatóan több, mint 935 milliárd dollár bevételt generálnak fizetett letöltések és alkalmazáson belüli hirdetések révén.

mobil-alkalmazások bevétele világszerte
A mobil-alkalmazások bevétele 2014 és 2023 között világszerte, milliárd USD-ben.

A Freemium (Free + Premium) üzleti modell jól bevált a gyártóknak. Töltsd le ingyenesen, és ha már elkötelezett vagy, akkor apró költésekkel fizetek ki az egészet.

A fentiek alapján látható, hogy megfelelő bevételszerzési stratégiával lehet jelentősebb bevételeket generálni.

Ezeket számold bele egy mobil-app projektbe

Eldöntötted, hogy mégis belevágsz. Egy mobil-alkalmazás megrendelése a végszó!

A következő feladatokat kell számolni:

  • Projekt tervezése
  • Felhasználói élmény tervezése (UX design)
  • Felületek tervezése (UI design)
  • Megvalósítás, ami általában a legnagyobb részét teszik ki a munkának
  • Marketing feladatok: előtte, induláskor, utána
  • Az alkalmazások frissítése (legalább fél évente), hibajavítások

A fejlesztési idő, és ezáltal a költségek egy része egy jó kereszt-platformmal (cross-platform) csökkenthetőek. Nem mindegy, hogy kétszer kell egy alkalmazást megírni, vagy egyszer, és Androidra vagy iOS-re csak igazítani apróságokat.

Én a Flutter kereszt-platformot használom. Ennek előnyeiről itt írtam korábban. Létezik számos másik, ezeket előtte érdemes egyeztetni a megrendelővel, hogy milyen funkciókat vár. Vannak-e korlátai, amik nem, vagy csak körülményesen teljesíthetőek?

A költségek csak az egyik szempont

Előfordul, hogy egy cégnek egy mobil app egy névjegyet jelent. Ki lehet tenni, megmutatni, hogy ilyen is elérhető a portfóliójában. Ez egyfajta presztízs dolog.

Ne feledkezzünk meg a megkívánt funkciókról. Szeretnénk-e ismétlődő értesítéseket küldeni a felhasználóinknak, ami a marketingre fordított költségeinket javíthatja. Kell-e bele GPS funkció? Netán egy magával ragadó játékot álmodtunk meg? Fontos, hogy offline is bármikor elő tudja kapni a felhasználó?

Segítségképpen összegyűjtöttem egy listát, hogy ötleteket adjon, hogy miket kell mérlegelni a döntés előtt. A listában számos szempont szerepel, amiket érdemes átgondolni. A funkciólista alapján kirajzolódik, hogy mire lesz szükségünk: app vagy weblap?

Ellenörző-lista : Mikor van szükségem mobil app-ra?

Az email címed megadásával elfogadod az Adatkezelés tájékoztatót, és feliratkozol a hírleveleimre.

Az első hírlevélben a beállításait módosíthatod.
Kérem Az Ingyenes Ellenörző-listámat

Ide kérem a letöltési linket:

Remélhetőleg a cikk segített egy sikeres döntés előkészítésében, és spórolni a költségeken.

Ha maradt még kérdésed, akkor egyeztessünk egy ingyenes megbeszélést, ahol tovább pontosíthatod a céljaidat.

Borítókép: Allef Vinicius | Unsplash