Arhitectura Fooodo
Cum este construit Fooodo — separarea în două servicii (aplicația de meniu și serviciul de plată), modelul de multi-tenant 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, accesibil 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 sursă 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 limitat 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ă revine.
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 baza care face posibile Plata ulterioară, î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ă, module 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 automat 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 tehnologică 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 plăți | Mollie (Card, Apple Pay, Google Pay) |
| 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, rambursări, metode de plată, bacșișuri, donații → serviciul de plată.
- Sursa de adevăr pentru meniu, tichete de bucătărie, rapoarte → POS-ul tău (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 îl accesează prin proxy.
Primii pași cu Fooodo
Calea practică de onboarding de la „tocmai am semnat" la 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.