Performance_TenantHawk

Versione performante di TenantHawk, scritta in C++

View repository on GitHub

README

GitHub Repo C++ Drogon Inja Astro TensorZero Node--RED PostgreSQL Redis Docker

Logo

Performance_TenantHawk - SaaS Template v1.0.0

A low-footprint SaaS foundation for builders who care about margin, not just launch speed.

Costruisci SaaS multi-tenant production-ready senza portarti dietro un runtime frontend pesante o uno stack che si mangia RAM appena lo accendi.

Backend SSR + landing statica + infra già predisposta: parti subito, non quando hai finito di rincorrere il boilerplate.

Questa variante nasce per essere più leggera, più diretta e molto più aggressiva sul rapporto performance/consumo.

Indice

Avvio Progetto

Terminale

Avviare il progetto è semplice: entra nella cartella root e lancia:

docker compose up --build

Con questo comando parti con lo stack reale attuale:

  • Traefik come reverse proxy
  • backend C++ con Drogon + Inja
  • landing Astro servita come statico via Nginx
  • PostgreSQL
  • Redis
  • TensorZero
  • Node-RED

Raccomandazione: crea il file .env nella root prima dell'avvio, così hai subito il controllo su porte, DB e chiavi applicative.

Endpoint locali principali:

  • http://www.localhost per la landing
  • http://admin.localhost per l'area admin SSR (Inja) via Traefik
  • http://admin.localhost:8000 per l'area admin SSR diretta sul backend
  • http://api.localhost/health per gli endpoint API/health non renderizzati
  • http://localhost:8000/health per l'healthcheck diretto del backend
  • http://tensorzero.localhost per il gateway LLM
  • http://nodered.localhost per il layer automazioni
  • http://localhost:8080 per la dashboard Traefik in locale

Monitoring risorse

Docker

Qui il punto non è solo “funziona”, ma “quanto pesa mentre funziona”.

Questa variante di TenantHawk nasce proprio per tagliare sprechi inutili:

  • niente runtime Next.js sempre acceso per la landing
  • niente doppio layer frontend app-oriented se ti serve solo marketing + SEO
  • backend SSR leggero con C++ e template server-side
  • servizi accessori separati e limitabili a livello container

I comandi principali che userai davvero sono:

docker compose up -d

Avvia lo stack in background

docker compose down

Ferma i container preservando volumi e dati

docker compose build

Rigenera le immagini dopo modifiche strutturali

docker compose up --build

Builda e avvia insieme, utile quando stai iterando veloce

ATTENZIONE: non usare in produzione docker compose down -v se non sai esattamente cosa stai facendo, perché rimuove anche i volumi persistenti.

Perché questa variante

Frontend

Questa non è una semplice “porta C++” del progetto originale: è una variante pensata per chi vuole la base TenantHawk ma con un profilo più aggressivo su risorse, avvio e semplicità operativa.

Il confronto, in termini pratici, è questo:

  • TenantHawk base: stack completo nell'ordine di 1.7 GB RAM
  • Performance_TenantHawk: variante alleggerita nell'ordine di 120 MB per il core web minimale

Tradotto: qui il focus non è tenere acceso un ecosistema enorme per fare una landing e un admin SSR, ma spremere il massimo dal minimo necessario.

Anche lato carico, la direzione è chiara: questa base è progettata e testata per spingersi oltre i 2000 VUs sui percorsi leggeri e sugli endpoint core, con benchmark da interpretare sullo scenario specifico e non come promessa universale.

Non è marketing vuoto: è una scelta architetturale precisa.

Backend

Backend

Il backend è costruito in C++17 con Drogon per l'HTTP server e Inja per il rendering template server-side.

Questa scelta cambia parecchio il profilo del progetto:

  • footprint molto più stretto rispetto a stack Python/Node equivalenti
  • tempi di risposta puliti sugli endpoint SSR semplici
  • bootstrap minimale
  • meno overhead applicativo per richieste di routing, healthcheck e pagine admin leggere

Ad oggi il backend include realmente:

  • route base e redirect iniziale
  • healthcheck applicativo
  • healthcheck PostgreSQL con connessione reale
  • route auth SSR
  • route admin SSR
  • caricamento .env locale con fallback alle env del processo
  • rendering HTML tramite Inja

In pratica: niente “finta app enterprise” piena di layer inutili, ma un nocciolo web diretto, leggibile e pronto da far crescere.

Admin - Backend

Admin

Il lato admin segue una filosofia semplice: rendering server-side, HTML pronto al primo colpo, niente SPA dove non serve.

Questo significa:

  • tempi di bootstrap più bassi
  • meno JS da tenere vivo lato browser
  • minore complessità operativa
  • più prevedibilità sotto carico

Per casi d'uso classici SaaS B2B, pannelli interni, backoffice, dashboard operative e form di autenticazione, questo approccio è spesso molto più efficiente del solito frontend ultra-client-side montato per inerzia.

Landing - Frontend

Landing

La landing ora è costruita con Astro e servita in produzione come statico via Nginx.

Qui c'è uno dei tagli più importanti rispetto al TenantHawk base.

Prima avevi un runtime Next.js sempre acceso anche per una parte che, nella maggior parte dei SaaS, è solo marketing, SEO e conversione.

Ora invece hai:

  • HTML statico generato in build
  • runtime estremamente leggero in produzione
  • ottima SEO grazie a markup già pronto al primo byte
  • meta tag, canonical, Open Graph, robots e sitemap gestibili senza overhead server-side Node

In altre parole: mantieni il PRO SEO senza pagare il costo RAM di un frontend framework pesante tenuto vivo 24/7 solo per mostrare una landing.

Traefik - Reverse Proxy

Traefik

Traefik resta il regista del traffico.

In locale hai un routing semplice e diretto:

  • www.localhost punta alla landing Astro servita da Nginx
  • admin.localhost punta alle pagine admin/auth SSR del backend C++
  • api.localhost espone solo endpoint API/health (/api/*, /health, /health/db)
  • tensorzero.localhost punta al gateway LLM
  • nodered.localhost punta al layer automazioni

Sono già presenti anche i router produzione per:

  • www.linkbay-cms.com
  • admin.linkbay-cms.com
  • api.linkbay-cms.com
  • tensorzero.linkbay-cms.com
  • nodered.linkbay-cms.com

La parte HTTPS/TLS è ancora commentata nel compose per lasciare il progetto più rapido da usare in sviluppo, ma la struttura resta pronta per essere estesa.

RICORDARSI DI METTERE UNA PROTEZIONE ALLA DASHBOARD TRAEFIK IN PRODUZIONE

PostgreSQL - Database

PostgreSQL è il database dello stack.

Qui non è messo come “opzione futura”: è già dentro al compose, con volume persistente, healthcheck e configurazione via env.

Questo ti permette di avere subito:

  • una base dati reale e persistente
  • healthcheck vero sul backend verso PostgreSQL
  • separazione pulita tra processo web e livello dati

È la scelta giusta quando vuoi partire da una base SaaS credibile, non da una demo che prima o poi devi rifare da zero.

Redis - Cache e supporto runtime

Redis è incluso nello stack come servizio leggero di supporto.

Anche quando non stai ancora usando tutte le sue capacità applicative, averlo già pronto significa poter introdurre senza attrito:

  • caching
  • rate limiting
  • code leggere
  • supporto a sessioni o lock futuri

Il valore qui è architetturale: non gonfia il progetto, ma ti evita il classico “poi lo integriamo” che puntualmente rallenta tutto appena il SaaS inizia a crescere.

TensorZero - Gateway LLM

TensorZero sostituisce LiteLLM come gateway LLM dello stack.

La logica resta molto concreta: separare l'applicazione dai provider LLM reali e tenere un punto unico di instradamento, configurazione e osservabilità.

Perché è utile in pratica:

  • cambi provider senza toccare il resto dello stack
  • mantieni le chiavi fuori dalla logica applicativa
  • tieni il layer AI in un servizio dedicato
  • puoi evolvere politiche, routing e configurazioni senza sporcare il backend

In più, nel compose è già limitato con mem_limit e cpus, proprio per evitare che un servizio accessorio diventi il solito divoratore di RAM non controllato.

Node-RED - Automazioni

Node-RED sostituisce n8n come layer di automazione.

La scelta qui è allineata al resto del progetto: tenere uno strumento semplice, rapido e più leggero, senza dover montare un'orchestrazione più pesante del necessario.

In questa variante la subscription logic viene spostata fuori dal core applicativo e affidata a Node-RED. Non perché il billing sia meno importante, ma perché l'obiettivo di PTH è tenere il backend C++ minimale, stabile e focalizzato sul serving. Le automazioni economiche restano modificabili senza ricompilare, senza sporcare il core e senza trasformare il backend in un centro di orchestrazione.

Con Node-RED puoi gestire bene:

  • workflow operativi
  • webhook interni
  • orchestrazioni tecniche
  • automazioni applicative e integrazioni

Anche qui il profilo è chiaro: servizio dedicato, utile, ma con limiti impostati per non trasformarlo in un peso ingestibile sul nodo che ospita tutto.

Test Performance

k6

Il focus di questa variante è andare nella direzione giusta anche sotto stress, non solo “stare in piedi in locale”.

Nel repository trovi già strumenti e script orientati ai test di carico, tra cui:

  • test/test_login.js
  • test/stress_crow.sh

L'obiettivo dichiarato di questa versione non è fermarsi ai classici test da MVP, ma spingere verso ordini di carico superiori a 2000 VUs sugli endpoint più leggeri e sui percorsi ad alta frequenza.

Perché questo conta davvero:

  • se la landing è statica, non stai sprecando memoria lato frontend
  • se il backend SSR è minimale, non stai pagando overhead inutile per ogni richiesta
  • se i servizi accessori sono separati e limitati, il comportamento sotto pressione resta più leggibile

In sintesi: questa base non nasce per fare scena nei benchmark, ma per tagliare attrito e restare credibile quando il traffico smette di essere “da demo”.

Perché questo template

  • Niente runtime frontend pesante dove non serve
  • Backend SSR in C++ con footprint molto più contenuto
  • Landing SEO-friendly senza server Node in produzione
  • Reverse proxy già impostato
  • Database e Redis già nello stack
  • Gateway LLM dedicato già previsto
  • Layer automazioni già separato
  • Struttura pronta per evolvere senza rifare tutto al primo cambio di direzione

Obiettivo: ridurre drasticamente il tempo che separa l'idea da un SaaS credibile, mantenendo un profilo RAM molto più aggressivo rispetto al TenantHawk base.

Quando usarlo

Perfetto per:

  • SaaS B2B
  • dashboard operative
  • admin panel SSR
  • piattaforme multi-tenant sobrie e veloci
  • MVP che devono partire con costi runtime bassi

Meno adatto per:

  • prodotti frontend-first molto interattivi
  • editor visuali complessi tipo Figma/Trello-like
  • app dove la maggior parte della logica vive nel browser

Licenza MIT

Sviluppatore: Quagliara Alessio

License: MIT