Nevoie de sfaturi despre arhitectură: rezultatele API in PHP si MySQL

[webSorin]

Salutări tuturor!
Dezvolt un website de turism care preia date din 8 API-uri diferite, fiecare deservind o țară, altele mai multe.
Am stocat în baza mea de date toate regiunile, orașele și hotelurile aferente.
Acum trebuie să listez prețuri pentru camerele disponibile.
Partea bună este că nu toate hotelurile vor fi active, lucru care este deja implementat în aplicația mea.

Problema este că API-urile nu pun la dispoziție rezultate implicite fără a cere parametri precum perioadă (start date - end date), nr. de persoane, nr. de copii.
Și eu am nevoie să afisez prețuri le hoteluri disponibile și când vizitatorul accesează o regiune.

Apoi, trebuie listate prețurile și când parte, sau toți parametrii sunt deja selectați de vizitator.

Problema mea este logica, arhitectura cea mai bună pentru a evita sumedenia de bucle în cronjob-uri care trebuiesc clădite.
Cel mai mult "mă încurcă" ideea de nr. nopți pentru că, după cum știți, 2 nopți începând cu o zi poate rezulta un preț, și alt preț când avem o altă zi.
La fel pentru 3, 5 ... X nopți.
Rezultă un întreg sistem de permutări care implică bucle în bucle și aș vrea să știu dacă există o metodă mai bună.

Și, ca să fie "treaba treabă", fiecare API este actualizat și de 3 ori pe zi...

O primă soluție ar fi să creez un cron pentru fiecare API care scoate prețurile pentru toate permutările posibile, pornind de la hotelurile active.
Acest cron să scrie datele într-un csv pe serverul meu, pentru ca apoi, să mai fac un cron care să facă insert/update cu acele date în tabelele mele.
Așa separ două secțiuni logice limitând numărul de interogări.

Rămâne doar cron-ul inițial care scoate răspunsurile de la API, plecând de la hotel, tipul camerei care poate fi afectat de nr de persoane/copii, la care se adaugă nr de nopți...
Voi cum ați aborda această problemă?
PS: aplicația este dezvoltată de la zero în PHP 8.2.

Mulțumesc!

[kleampa]

Salut,
Pune "din burta" o perioada plecare/durata/2 adulti pentru a-i putea genera pret (pt camera cea mai ieftina). Iar copy-ul sa fie "de la XXX eur"

E chestie de UX mai mult decat de programare. E logic ca doar pentru "regiune", fara sa stii nimic despre cererea omului, n-ai ce pret sa-i afisezi.

[webSorin]

Așa mă gândeam și eu, să plec inițial cu un set de date fixe, cele mai uzitate pentru a rezolva problema imediată a listării celui mai mic preț:
1 noapte, 2 .., pănă la 14.
Dar apoi intervine problema cu nr de persoane - care, deși pot fi limitate de tipul camerelor, tot îmi va genera o groază de permutări care trebuie adresate în cod.
Și, peste astea mai intervine problema "viitorului": ce faci când în website se cer date despre septembrie 2015, să zicem?
Cron-ul ăla inițial trebuie să acceseze și să stocheze tone de date...

[kleampa]

am facut si eu un site similar (https://vacanteturcia.ro/) si am preferat varianta de a "da in api" la fiecare request. am si un cache local de cateva ore pentru interogarile cu aceiasi parametrii

[webSorin]

Mulțumesc!
Cred c-o să aplic o variantă hibrid: cron + API request, după caz.
Vreau să văd și dacă API-urile au niște perioade limită sau orice altceva de care mă pot agăța pentru a constrânge volumul de date.

[felix]

Ce a raspuns ChatGPT, poate ajuta la ceva :
Abordarea problemelor tale legate de interogarea API-urilor și gestionarea datelor pentru prețurile camerelor de hotel într-o aplicație de turism poate fi optimizată urmând câteva strategii clare și eficiente. Iată cum aș aborda această problemă:

1. Stocarea datelor statice și dinamice
- **Date statice**: Regiuni, orașe, hoteluri, tipuri de camere etc. Acestea ar trebui stocate în baza de date și actualizate periodic (ex. o dată pe zi).
- **Date dinamice**: Prețuri și disponibilități, care se schimbă frecvent și necesită actualizări mai dese.

2. Utilizarea unui mecanism de cache
Pentru a reduce numărul de interogări directe la API-uri și pentru a îmbunătăți performanța, poți utiliza un mecanism de cache (ex. Redis, Memcached). Datele despre prețuri și disponibilități pot fi stocate temporar în cache, actualizate la intervale regulate sau la cerere.

3. Optimizarea cronjob-urilor
În loc să faci permutări exhaustive pentru toate posibilitățile, poți folosi o strategie de actualizare incrementală și pe bază de cerere:
- **Actualizări regulate**: Setează cronjob-uri pentru a actualiza datele de la API-uri la intervale regulate (ex. la fiecare 6-8 ore), acoperind o perioadă de timp standard (ex. 30 de zile în avans).
- **Actualizări la cerere**: Când un utilizator selectează parametri specifici (perioadă, nr. de persoane), poți face interogări specifice în timp real pentru a obține cele mai recente prețuri și disponibilități.

4. Structurarea bazei de date
Asigură-te că baza de date este bine structurată pentru a gestiona volume mari de date și interogări frecvente. Utilizează indici și particionare a tabelelor pentru a îmbunătăți performanța interogărilor.

5. Strategie de fallback
În cazul în care un API nu este disponibil sau nu răspunde, poți implementa o strategie de fallback care să utilizeze datele cele mai recente din cache sau din baza de date pentru a oferi utilizatorului informații aproximative.

Exemplu de implementare
1. **Cronjob pentru actualizări regulate**:
- Rulează la fiecare 6 ore.
- Interoghează API-urile pentru perioade standard (ex. următoarele 30 de zile).
- Stochează rezultatele în cache și/sau baze de date.

2. **Interogări la cerere**:
- Când un utilizator selectează o perioadă specifică, interoghează API-ul pentru datele specifice.
- Actualizează cache-ul cu noile date.

3. **Arhitectura bazei de date**:
- Tabel pentru hoteluri (hotel_id, name, location, etc.).
- Tabel pentru tipuri de camere (room_type_id, hotel_id, description, etc.).
- Tabel pentru prețuri și disponibilități (price_id, room_type_id, date, price, availability, last_updated).

Pseudocod pentru cronjob
```php
function updateHotelPrices() {
$hotels = getActiveHotels(); // Obține hotelurile active din baza de date
$apiResults = [];

foreach ($hotels as $hotel) {
foreach (getRoomTypes($hotel) as $roomType) {
$startDate = date('Y-m-d');
$endDate = date('Y-m-d', strtotime('+30 days'));

for ($date = $startDate; $date <= $endDate; $date = date('Y-m-d', strtotime($date . ' +1 day'))) {
$response = queryApi($hotel, $roomType, $date);
$apiResults[] = [
'hotel_id' => $hotel['id'],
'room_type_id' => $roomType['id'],
'date' => $date,
'price' => $response['price'],
'availability' => $response['availability'],
'last_updated' => date('Y-m-d H:i:s')
];
}
}
}

storeApiResults($apiResults); // Stochează rezultatele în baza de date
}
```

Această abordare minimizează numărul de interogări prin utilizarea de cache și actualizări incremental și la cerere. Asigură-te că toate componentele sunt bine integrate și testate pentru a gestiona diverse scenarii și pentru a asigura o performanță optimă.

[webSorin]

Salut Felix.
Mulțumesc pentru sugestie dar ChatGPT nu este o soluție optimă. Sigur, unele sugestii sunt logice dar punea în practică este problema.
Sunt API-uri cu mii și mii de hoteluri peste tot în lume...
Chat GPT nu-i în stare nici să înțeleagă complexitatea, dar să mai ofere și soluții...
Pentru că dacă-i spui lui CHatGPT că unele api-uri vor avea și 1000 de hoteluri, iar tot din acele hoteluri multe vor avea prețuri din mai multe API-uri... o să facă scurt circuit ChatGPT și o să-ți spună iar cum să clădești tabela "hoteluri"