Mit gondolsz, mennyi pénzedbe és idődbe kerülne lefejleszteni egy olyan appot, ami QR kódos étlapot kezel sok étteremben, lehet rendelni/fizetni applikációból, keresni kajákra, éttermekre, ezeket értékelni, kommentelni, és még van hozzá rendelés kezelő is az étterem számára? Több 10 millió forint, több hónap! Mondaná neked egy tetszőleges cég. Mit mond erre a Garlic? Esettanulmány és cikk sorozat.
Azt, hogy megpróbáljuk ezt a lécet megugrani 8 óra alatt. Ez idő alatt App Store-ba szeretnék vinni egy komplett QR kódos rendelős appot, ami képes kiszolgálni több éttermet, felhasználó és termék menedzsmenttel, backenddel, kártyás fizetéssel, mindennel. Lehetetlen? Meglátjuk!
Ez itt egy cikksorozat lesz, ami végig dokumentálja ezt a 8 órát. Nem lépésről-lépésre instrukciók lesznek, hanem inkább esettanulmány, egy érdekes megközelítésről. A nulláról eljutunk majd egy gráf adatbázis alapú éttermi megoldásig, plusz egy-két innovatívabb ötlet megvalósításáig.
A cikket a Minner következő munkája inspirálta:
ami után csak elismerő csettintésre futotta. Milánék no-code megoldásokat teszteltek, ami pont egybevágott azzal, hogy pár napja én is életemnek abba a szakaszába léptem, amikor az emberek elkezdenek no-code és egyéb költség csökkentő, fejlesztés felgyorsító megoldásokat tesztelni. Ez ügyben az én választottam a Flutterflow lett. Mivel ez az írás nem a no-code-ról szól, ezért itt csak összefoglalom, hogy állok ezzel a témával:
No-code
Pro: gyorsan lehet velük dolgozni, tényleg nem igényel nagy háttértudást az eleje, a végeredmény pedig általában hibátlan, és még szép is tud lenni.
Con: hamar belefutunk a limitációkba, ha már olyan extra funkciót kell beletenni, amit a rendszer (még) nem támogat, akkor a nehézségek exponenciálisan nőni kezdenek. A generált kódba embernek benyúlni nehézkes, és nem is ajánlott. Az oka kézenfekvő, ezek a generátorok a gép számára írnak kódot, nem az ember számára, így azok a “fölösleges” koncepciók, amik alapvetően csak az emberi agynak fontosak ("clean" architektúra, stb), itt nem játszanak.
Szóval a no-code, véleményem szerint, akkor fog igazi áttörést jelenteni, ha megoldják, hogy az ember és a gép képes legyen egy kódbázison együtt dolgozni, és oda-vissza megértsék egymást. Most itt még nem tartunk. Bár… Flutterflowban vannak ötleteim, ha sikerül valamilyen módon megoldani ezt a kooperációt valamilyen külső eszközzel, akkor az sokat dobna a helyzeten. Ezzel még lehet, hogy visszajövök 🤔.
App kitek
Na jó, ha nem no-code, akkor marad a full-code, nem? Azzal meg hogy is fogom ezt a feladatot megugrani. Mondom akkor az elképzelést:
Az appok általában soha sem egyediek. Minden rendszerhez már van hasonló, akár házon belül is. Erre pedig fejlesztő cégek is rárepültek, akik azt használják ki, hogy kevesebb megoldandó probléma létezik, mint ötlet rájuk, de még a problémák is hasonlítanak egymásra. Ezekre a problémákra pedig kifejlesztettek általános megoldásokat, amikből kiindulva már csak azt kell beletenni, ami a saját projektünkben egyedi. Ez tehát kicsit hasonlít a nocode-hoz, hiszen az elején nem kell kódolni 🙂 Ha szerencsénk van, és találunk ilyen megoldást a piacon, akkor azzal több ezer munkaórányi fejlesztést is megspórolhatunk!
Na ez az elmélet, ezt fogjuk letesztelni a gyakorlatban. Tehát a feladat: fejlesszük le a köv rendszer prototípusát, amely:
több éttermet kezel egy közös platformon
minden étteremnek van saját étlapja
az egyes kaják konfigurálhatóak (azaz kávét kérek tejjel)
a rendelést azonnal ki lehet fizetni
a felhasználók tudnak regisztrálni
lehessen benne asztalt foglalni
lehessen benne házhozszállítást kérni
az étterem tudja menedzselni az ő oldaláról a rendeléseket
lehessen kommentelni, legyenek benne push értesítések, trendek figyelése, nagy rakás funkció
Ja igen, és:
lehessen QR kódon keresztül asztalhoz is rendelni 😃
Mit figyelhetünk meg? Azt, hogy a QR kódos asztalhoz rendelésen kívül alapvetően ledefiniáltunk egy olyan rendszert, amiből több ezer van már a piacon (de QR kódos is jó pár) - biztos, hogy ezt nekünk is le kell fejlesztenünk? Hát nem!
Keressünk akkor kész megoldást, amibe már csak bele kell tenni az asztalos cuccot, és még technikailag kezelni is tudjuk. Rövid keresés után megtaláltam ezt:
Ez pedig a leírás alapján mindent IS tud, ami nekünk kell, Flutterben van írva az app, hát akkor… ez esélyessé teszi, hogy ebben a feladatban sikert is érjünk el. Szóval: megvesszük a csomagot, életet lehelünk bele, és belefejlesztjük a QR kódos részt. 8 óra alatt? Nézzük meg!
T + 0:00: project start, vásárlás
Regisztrálunk a web oldalon, számla, kártya adatok, klikk a fizetésre. A folyamat zökkenőmentes, 5 perc múlva le is töltöttem a csomagot, unzipelve. Nézzük, mi vettünk.
T + 0:05: unboxing
Mi van a dobozban. Három mappát látunk:
A Flutter app kód, a backend + admin felület kód, és a dokumentáció.
App kód
Hogy néz ki az applikáció kód? Hát ez, a terminológiát nézve, nagyjából clean-nek tűnik, felismerhetőek a rétegek. Az egyes rétegeken belül szépen, funkciók szerint rendezve ott a kód. Sima provider alapon fejlesztették le a srácok. Ez pedig azt jelenti, hogy a fejlesztést innen gond nélkül át lehet venni.
Backend
Jó, hát itt biztonsági játékot játszottak a fejlesztők, sima PHP cucc. Nincs ezzel semmi baj, bele lehet pakolni a változtatásokat, de ez azért inkább már cserélős. Mint említettem, gráf... Az admin viszont nem nagy bonyodalom, de ezt fogja elsőnek falhoz állítani a forradalom, ezt már értelmesebb lesz átírni - mondjuk Flutter web alapon? 🤔
Az adatbázis sima SQL, combos mennyiségű minta adattal, ez pedig már önmagában is érték.
Na de a konklúzió: az app bíztató, ide szerintem bele lehet majd préselni az QR kódos extra funkciót simán. DE! Mindenek előtt kell egy app név, valami bundle azonosító, amivel a cucc már kimehet akár store-ba is.
A Név
Legyen mondjuk… yaRa. Yet Another Restaurant App. Mellékszál, de van már egy hasonló nevű kezdeményezés, más témában, de arról majd máskor 😎
Kezdjük akkor végrehajtani a konfigurálást!
T + 0:10: backend konfigurálás
A munka érdemi része akkor most kezdődik: fel kell éleszteni a backendet, és be kell konfigurálni. Ehhez a user guide fogta meg a kezünket, elég részletes az anyag, néhol magyarázós is, akár youtube videokkal. Kell akkor:
valami, ahol hostoljuk az adatbázist és az admin frontendet. Az most, első körben, egy sima docker compose alapú megoldás lesz, amit saját szerveren hostolok. Felhő kellene, igen, de ez most egy teszt, szóval emiatt nem akarok felhővel variálni + fizetni érte. Docker compose, csak menjen
kell egy firebase projekt, mert a felhasználó kezelés, a push üzenet küldés firebase alapú
kell egy Stripe account, ugyanis a kártyás fizetés stripe integrációval megy
Ezen a ponton kilépünk a doksiból, és felhúzunk egy docker alapú backendet. Itt csak kulcsszavakban: php, ngnix, mysql containerek, szóval a jó öreg alapok azoknak, akik még éltek a web1 világban.
Már most mondom, hogy ez nem a vége, mert a backenden, a következő cikkekben, érdekes dolgok fognak történni, meg fogjuk nézni, hogy mit lehet kezdeni akkor, ha mindenféle szolgáltatásokat integrálunk be a cuccba. De most a klasszikus út.
Mondjuk lekövetheted ezt. Ennek alapján (egy kis extrával 😉), fél óra múlva fel is állt a backend, elindult az admin felület:
Minta adatok betöltése után voilà:
Eddig menő!!! 🎉 Rengeteg funkció van a cuccban, ebből meg is lehetne élni. Nnnna, konfiguráljuk be az appot akkor.
T + 0:50: firebase konfig
...de ezt a következő postban 🙂
Comments