Prodotto proprietario · engineering multi-repository
Oriqoprodotto, execution e infrastruttura come un unico sistema.
Prodotto software proprietario in sviluppo con frontend pubblico, backend autorevole, runtime tool isolato e infrastruttura di distribuzione coordinati come un unico sistema.
Oriqo è IP proprietaria. Il case study espone architettura e confini di engineering senza pubblicare accesso al prodotto, repository privati, endpoint operativi o secret.
Ambito del prodotto
Una superficie pubblica sostenuta da piani autorevoli ed esecutivi separati
Oriqo si è evoluto oltre la singola applicazione web. L’architettura di deployment corrente coordina un frontend Nuxt pubblico, un backend FastAPI autorevole, un runtime tool isolato e un repository infrastrutturale dedicato, con ownership tecniche esplicite.
Superficie prodotto pubblica
Il frontend Nuxt possiede SSR/SEO, autenticazione browser, Account Center, Resource Graph, delivery dei tool e Integrated Admin Center consumando contratti backend browser-safe.
Backend autorevole
FastAPI possiede account, autenticazione, entitlement, metadata Tool Platform, control plane Resource Graph, stato PostgreSQL/Alembic, Redis e rate limiting.
Execution plane privato
L’esecuzione dei tool è isolata dietro un contratto HTTP interno con runner allow-listed, manifest versionati e immagine OCI non-root, invece di avvenire nel frontend pubblico.
Architettura
Confini chiari dalla richiesta browser all’esecuzione privata
Il browser usa route same-origin del frontend. Il frontend inoltra contratti browser-safe al backend; il backend resta autorevole sullo stato del prodotto e invia al runtime interno solo le esecuzioni private dei tool. L’infrastruttura collega i livelli senza esporre direttamente i servizi interni.
01
Frontend pubblico
Nuxt 4 · Vue · TypeScript · SSR/SEO · auth browser
02
Backend autorevole
FastAPI · auth/account/entitlement · Resource Graph · Tool Platform
03
Tool runtime
HTTP/JSON privato · runner allow-listed · manifest immutabili
04
Infrastructure
Nginx · Compose · rete privata · digest immutabili
Sicurezza e delivery
I vincoli operativi fanno parte dell’architettura del prodotto
Il modello di delivery separa intenzionalmente build, deploy e autorità runtime. I repository applicativi pubblicano artefatti; Infrastructure decide quali artefatti immutabili eseguire nell’ambiente di integrazione; la production resta una decisione esplicita e non la conseguenza automatica di un merge.
I servizi interni restano interni
Backend, PostgreSQL, Redis e tool runtime non pubblicano porte host nella topologia di deployment; Nginx è il gateway esterno.
Flusso artefatti immutabile
Backend e tool runtime pubblicano immagini OCI non-root su GHCR. Infrastructure consuma digest fissati invece di tag latest mobili.
Secret host-side
Credenziali runtime e token interni restano fuori dai repository e non appartengono alla superficie pubblica del case study.
Rollback progettato
Infrastructure possiede smoke, rollback immagini e contratti di backup/restore, mentre il downgrade database resta un problema separato e controllato.
Governance di engineering
Multi-repository senza effetti collaterali cross-repository nascosti
Oriqo mantiene issue, branch, pull request e gate di validazione repository-scoped anche nel modello operativo single-developer. GitHub è la fonte canonica e la production non è mai implicita nel lavoro di integrazione.
Il lavoro segue una progressione esplicita work branch → integrazione → production.
Un work item autorizza un repository target e un output verificabile; necessità cross-repository tornano alla governance invece di ampliare silenziosamente lo scope.
Frontend, backend, tool runtime e infrastructure mantengono contratti di ownership tecnica distinti.
La precedente Admin App standalone è ritirata dalla topologia attiva; le capacità amministrative correnti sono integrate nella superficie web del prodotto.
Attività svolte
Responsabilità di prodotto attraverso software, dati, sicurezza e delivery
Il case study riflette definizione del prodotto, architettura e implementazione attraverso frontend pubblico, contratti backend, livello dati, autenticazione, isolamento runtime, infrastruttura e workflow di rilascio controllato.
Responsabilità
Aree di lavoro
Tecnologie
Uno stack scelto per confini di prodotto espliciti
Le tecnologie sono organizzate per responsabilità: prodotto browser, API/dati autorevoli, execution isolata e delivery infrastrutturale. L’architettura conta più del singolo framework.
Stato attuale
L’ambiente di integrazione è attivo; la production resta separata
I repository correnti documentano lavoro vivo di integrazione su frontend, backend, tool runtime e infrastructure. Oriqo resta proprietario e in sviluppo attivo: questa pagina non implica disponibilità pubblica del prodotto, rollout production o accesso a superfici operative private.