Arhitectura Fooodo
Cum este construit Fooodo — separarea în două servicii a aplicației de meniu și a serviciului de plată, modelul de multi-tenancy companie/restaurant/masă, contractul de conector POS-agnostic și locul unde se află UVS.
Fooodo funcționează ca două servicii care cooperează, plus un POS extern, accesat printr-un contract de conector POS-agnostic. Această pagină reprezintă harta sistemului: cum se conectează componentele, de ce sunt separate și cum funcționează multi-tenancy-ul.
Cele două servicii
- Aplicația de meniu. Fluxul orientat către client (QR → navigare → comandă), panoul de administrare pentru operatori și tot traficul conectorului POS.
- Serviciul de plată. Serviciu separat, accesibil printr-un API autentificat prin token. Deține integrarea Mollie, rutarea webhook-urilor, rutarea donațiilor și rutarea bacșișurilor. Are propriul panou de administrare intern.
- Conectorul POS. Oricare POS pe care îl utilizează restaurantul. Fooodo îl tratează ca sistem de referință pentru meniu și ca sursă de adevăr a bucătăriei pentru comenzi. R-Keeper este conectorul de referință activ în prezent; alți conectori POS sunt definiți per client — contractul conectorului în sine este POS-agnostic.
Cele două servicii Fooodo comunică printr-un API HTTP autentificat; nu există bază de date comună, coadă comună sau implementare comună. Pot fi implementate independent.
De ce este separat serviciul de plată
Trei motive:
- Domeniul de conformitate rămâne restrâns. Datele cardului ating exclusiv serviciul de plată; aplicația de meniu primește un URL de checkout și un callback. Domeniul PCI este delimitat la o singură bază de cod.
- Serviciul de plată este reutilizabil. A fost conceput pentru a deservi mai multe suprafețe Fooodo în timp, nu doar aplicația de meniu actuală. Produsele noi îl consumă fără a reimplementa infrastructura de plată.
- Izolarea defecțiunilor. Dacă Mollie are o întrerupere regională, aplicația de meniu rămâne funcțională; comenzile se pun în coada stării „gata de plată" și se reconciliază când serviciul de plată se recuperează.
Multi-tenancy
Fiecare înregistrare din aplicația de meniu este delimitată prin această ierarhie:
- Companytenant boundary · brand · billing
- RestaurantPOS config · hours · default flow
- TableQR code · per-table flow override
- Orderitems · payments · tips · donations
- Compania reprezintă granița tenant-ului. În prezent există o singură companie activă în producție (Čili Pizza), dar separarea tenant-urilor este aplicată peste tot — adăugarea unui al doilea lanț nu necesită o implementare separată.
- Administratorii de restaurant pot gestiona doar propriul restaurant — sistemul de roluri aplică acest lucru la nivelul politicilor.
- Fiecare cod QR se rezolvă la o masă specifică dintr-un restaurant specific. Nu există un cod comun „scanează pentru a comanda"; Fooodo știe întotdeauna pentru ce loc este destinată o comandă. Aceasta este ceea ce face posibile plata ulterioară (Pay-Later), împărțirea notei la masă și analiza la nivel de loc.
Unde se află UVS
UVS este nucleul de comenzi și operațiuni din interiorul aplicației de meniu — fluxul central de evenimente care înregistrează tot ceea ce scrie platforma (comenzi, plăți, starea meselor, tichete de bucătărie) înainte de a le propaga consumatorilor (conectorul POS activ, serviciul de plată, modulele viitoare).
Pentru integratori, acest lucru contează concret: modulele nu comunică direct între ele, iar contractul este POS-agnostic. Un conector pentru un POS nou nu atinge fluxul de bucătărie sau serviciul de plată — vorbește contractul UVS și moștenește gratuit plățile, multi-tenancy-ul și raportarea. R-Keeper este o implementare a acelui contract; contractul în sine este sistemul. Contractul este documentat în repo-ul de integrare, pe care partenerii îl primesc în timpul procesului de onboarding.
Stiva pe scurt
| Componentă | Formă |
|---|---|
| Aplicația de meniu | Backend PHP, frontend React, PostgreSQL, coadă de joburi bazată pe Redis |
| Serviciul de plată | Serviciu PHP independent cu propria bază de date și panou de administrare |
| Furnizor de plată | Mollie (Card, Apple Pay, Google Pay, Trustly) plus numerar pentru oaspeții autentificați |
| Conector POS | R-Keeper (activ); alți conectori POS definiți per client |
| Site de marketing | Next.js + next-intl + Fumadocs (acest site) |
Versiunile specifice ale framework-urilor sunt omise intenționat din această suprafață publică — partenerii care construiesc conectori POS primesc fixarea versiunilor în timpul onboarding-ului, alături de repo-ul de integrare.
Ce se află unde
- Gestionarea meniului, comenzi, mese, fluxul orientat către client → aplicația de meniu.
- Datele cardului, metode de plată, bacșișuri, donații → serviciul de plată.
- Sursa de adevăr a meniului, tichetele de bucătărie, rapoarte → POS-ul dumneavoastră (R-Keeper în prezent, alți conectori pe măsură ce sunt lansați).
- Conținut de marketing, documentație publică, asistent AI, server MCP → acest site.
Dacă integrați cu Fooodo, suprafața API care vă interesează este API-ul extern al aplicației de meniu. Serviciul de plată este intern — aplicația de meniu face proxy către acesta.
Primii pași cu Fooodo
Calea practică de onboarding de la „tocmai am semnat" la primele comenzi live la prima ta locație — sincronizarea meniului, mesele QR, repetițiile generale și ce să urmărești în prima săptămână.
Fluxuri de comenzi — Pay-First vs Pay-Later
Când să utilizați Pay-First față de Pay-Later, cum se comportă fiecare de la capăt la capăt, stările comenzilor pe care operatorii le văd în panoul de administrare și procesele de fundal care mențin comenzile sincronizate cu POS-ul.