Fooodo architektūra
Kaip sukurtas Fooodo — dviejų paslaugų padalijimas į meniu programą ir mokėjimo paslaugą, įmonės/restorano/stalo kelių tenantų modelis, POS-agnostinė jungties sutartis ir kur yra UVS.
Fooodo veikia kaip dvi bendradarbiaujančios paslaugos ir išorinis POS, pasiekiamas per POS-agnostinę jungties sutartį. Šis puslapis yra sistemos žemėlapis: kaip dalys jungiasi, kodėl jos atskirtos ir kaip veikia kelių tenantų modelis.
Dvi paslaugos
- Meniu programa. Kliento sąsajos srautas (QR → naršymas → užsakymas), operatoriaus administravimo skydelis ir visas POS jungties srautas.
- Mokėjimo paslauga. Atskira paslauga su prieiga per token autentifikuotą API. Valdo Mollie integraciją, webhook maršrutizavimą, aukų maršrutizavimą ir arbatpinigių maršrutizavimą. Turi savo vidinį administravimą.
- POS jungtis. Bet kuris POS, kurį naudoja restoranas. Fooodo laiko jį pagrindiniu meniu šaltiniu ir virtuvės tiesos šaltiniu užsakymams. R-Keeper šiandien yra veikianti etaloninė jungtis; kitos POS jungtys apimamos kiekvienam klientui atskirai — pati jungties sutartis yra POS-agnostinė.
Dvi Fooodo paslaugos bendrauja per autentifikuotą HTTP API; nėra bendros duomenų bazės, bendros eilės ir bendro diegimo. Jas galima diegti nepriklausomai.
Kodėl mokėjimo paslauga atskirta
Trys priežastys:
- Atitikties apimtis išlieka maža. Kortelių duomenys liečia tik mokėjimo paslaugą; meniu programa gauna atsiskaitymo URL ir atgalinį iškvietimą. PCI apimtis apribota viena kodo baze.
- Mokėjimo paslauga yra daugkartinio naudojimo. Ji buvo sukurta aptarnauti kelias Fooodo sąsajas laikui bėgant, o ne tik dabartinę meniu programą. Nauji produktai ją naudoja neįgyvendindami mokėjimų infrastruktūros iš naujo.
- Gedimų izoliacija. Jei Mollie patiria regioninę prastovą, meniu programa veikia toliau; užsakymai laukia būsenoje „paruošta apmokėti" ir suderinami, kai mokėjimo paslauga atsigauna.
Kelių tenantų modelis
Kiekvienas įrašas meniu programoje yra apribotas šia hierarchija:
- Companytenant boundary · brand · billing
- RestaurantPOS config · hours · default flow
- TableQR code · per-table flow override
- Orderitems · payments · tips · donations
- Įmonė yra tenanto riba. Šiuo metu gamyboje veikia viena aktyvi įmonė (Čili Pizza), tačiau tenantų atskyrimas yra užtikrinamas visur — norint pridėti antrą tinklą, nereikia atskiro diegimo.
- Restoranų administratoriai gali valdyti tik savo restoraną — vaidmenų sistema tai užtikrina politikos lygmeniu.
- Kiekvienas QR kodas nukreipia į konkretų stalą konkrečiame restorane. Nėra bendro „nuskenuok ir užsisakyk" kodo; Fooodo visada žino, kuriai vietai skirtas užsakymas. Tai leidžia naudoti mokėjimą vėliau, sąskaitos padalijimą prie stalo ir analitiką pagal vietą.
Kur yra UVS
UVS yra užsakymų ir operacijų branduolys meniu programoje — centrinis įvykių srautas, kuris fiksuoja viską, ką platforma įrašo (užsakymus, mokėjimus, stalo būseną, virtuvės bilietus), prieš perduodamas vartotojams (aktyviai POS junčiai, mokėjimo paslaugai, būsimiems moduliams).
Integruotojams tai turi konkrečią reikšmę: moduliai tiesiogiai tarpusavyje nekomunikuoja, o sutartis yra POS-agnostinė. Naujo POS jungtis neliečia virtuvės srauto ar mokėjimo paslaugos — ji kalba UVS sutarties kalba ir automatiškai gauna mokėjimus, kelių tenantų modelį ir ataskaitų teikimą. R-Keeper yra vienas tos sutarties įgyvendinimas; pati sutartis yra sistema. Sutartis dokumentuota integracijos saugykloje, kurią partneriai gauna prisijungimo metu.
Trumpa technologijų apžvalga
| Komponentas | Forma |
|---|---|
| Meniu programa | PHP backend, React frontend, PostgreSQL, Redis pagrindu veikianti užduočių eilė |
| Mokėjimo paslauga | Nepriklausoma PHP paslauga su sava duomenų baze ir administravimu |
| Mokėjimo teikėjas | Mollie (kortelė, Apple Pay, Google Pay, Trustly) ir grynaisiais prisijungusiems svečiams |
| POS jungtis | R-Keeper (veikianti); kitos POS jungtys apimamos kiekvienam klientui atskirai |
| Rinkodaros svetainė | Next.js + next-intl + Fumadocs (ši svetainė) |
Konkretūs karkasų versijų numeriai tyčia nenurodyti šiame viešame paviršiuje — partneriai, kuriančios POS jungtis, gauna versijų prisegimą prisijungimo metu kartu su integracijos saugykla.
Kas kur yra
- Meniu valdymas, užsakymai, stalai, kliento sąsajos srautas → meniu programa.
- Kortelių duomenys, mokėjimo metodai, arbatpinigiai, aukos → mokėjimo paslauga.
- Meniu tiesos šaltinis, virtuvės bilietai, ataskaitos → jūsų POS (šiandien R-Keeper, kitos jungtys kai bus pristatytos).
- Rinkodaros turinys, viešoji dokumentacija, AI asistentas, MCP serveris → ši svetainė.
Jei integruojatės su Fooodo, jus dominantis API paviršius yra meniu programos išorinis API. Mokėjimo paslauga yra vidinė — meniu programa perduoda užklausas jai.
Pradedame su Fooodo
Praktinis prisijungimo kelias nuo „ką tik pasirašėme" iki gyvų užsakymų pirmoje jūsų vietoje — meniu sinchronizavimas, QR stalai, bandomasis paleidimas ir ką stebėti pirmą savaitę.
Užsakymų srautai — Mokėjimas iš anksto ir Mokėjimas vėliau
Kada naudoti mokėjimą iš anksto ir mokėjimą vėliau, kaip kiekvienas srautas veikia nuo pradžios iki pabaigos, kokias užsakymų būsenas operatoriai mato administravimo skydelyje ir kokie foniniai procesai sinchronizuoja užsakymus su POS.