# Infrastruttura e booking per una piattaforma di tour operating.

> Una piattaforma di tour ed esperienze in Italia, con frontend Next.js, API Laravel e channel manager collegato via gRPC. Lo sviluppo applicativo è del cliente; noi governiamo infrastruttura, deploy e integrazione.

- Settore: Turismo e hospitality
- Ambito: Cloud e infrastruttura
- Anno: 2025-2026
- URL: https://cloudfactory.it/lavori/infrastruttura-booking-tour-operator/

## In breve

Su AWS, con Laravel Forge, gestiamo i server di una piattaforma turistica: frontend Next.js, API Laravel con code e scheduler, ambienti di staging e un plugin gRPC che collega la piattaforma al channel manager delle esperienze, Bokun. Nel 2026 abbiamo replicato la stessa architettura da zero per un secondo marchio, con dati separati, e la produzione è andata online in due giorni dal provisioning.

- **2** marchi sulla stessa architettura
- **5** siti per marchio tra produzione, staging e plugin
- **2** giorni dal server nuovo alla produzione del secondo marchio

## Contesto

Il cliente sviluppa la propria piattaforma con un team esterno: uno sviluppatore e una project manager. A noi spettano server, DNS, certificati, configurazioni web e l'integrazione con il channel manager.

## Il problema

Il channel manager si collega ai fornitori esterni tramite un plugin gRPC: un servizio Java sempre attivo, che richiede una configurazione nginx dedicata. In più ogni sito deve avere chiavi di deploy proprie, perché GitHub non permette di usare la stessa chiave su più repository.

## Cosa abbiamo fatto

1. **Siti isolati.** Ogni sito gira con il proprio utente di sistema: frontend Next.js gestito da Supervisor, API Laravel con code e scheduler, PHP 8.4, MySQL 8, Redis, Node 22. Uno sviluppatore che sbaglia un deploy non tocca gli altri siti.
2. **Il plugin gRPC.** Servizio Java sotto systemd, pubblicato con TLS tramite nginx, con controllo di salute, rotazione dei log e parametri della JVM. Dai log di accesso abbiamo individuato una registrazione fatta come REST invece che gRPC lato channel manager, e l'abbiamo fatta correggere.
3. **Una chiave per sito.** Ogni utente ha la sua chiave di deploy, registrata in sola lettura sul proprio repository. Script di deploy espliciti: pull, dipendenze, migrazioni, riavvio delle code e del processo Node.
4. **Un secondo marchio, da zero.** Stessa architettura su un server nuovo, database proprio e chiavi applicative nuove: i due marchi non condividono dati. Il team del cliente gestisce in autonomia deploy, code e scheduler dal pannello.

## Com'è andata

Il secondo marchio è andato in produzione in due giorni dal provisioning del server. Lo sviluppatore del cliente lavora in autonomia sui propri siti; noi teniamo AWS, DNS, nginx e l'integrazione con il channel manager.

## Strumenti

AWS EC2, Laravel Forge, Laravel 12, Next.js, PHP 8.4, MySQL 8, Redis, Node 22, Java 11, gRPC, nginx, Supervisor

## Domande frequenti

### Possiamo tenere il nostro team di sviluppo?

Sì, è il caso tipico. Noi ci occupiamo di infrastruttura e integrazioni, il vostro team continua a sviluppare l'applicazione.

### Cos'è un plugin gRPC per un channel manager?

Alcuni channel manager, come Bokun, si collegano ai fornitori esterni tramite un plugin che espone un servizio gRPC. Lo ospitiamo, lo pubblichiamo dietro TLS e lo teniamo attivo e monitorato.

---

Cloudfactory S.r.l., Roma. Contatti: hello@cloudfactory.it