davideandClaude Sonnet 5
84313b1955
CLAUDE.md, docs/PORTABILITA.md e mem/features/cloud-efficienza.md riflettono che rosa/classifica/storico partite vengono ora da Strapi (non più hardcoded) e che lo scout finalizzato viene anche inviato a Strapi, oltre al localStorage. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2.4 KiB
2.4 KiB
Portabilità di CrAPP
Regola di progetto: l'app deve poter girare su un normale server Node.js + PostgreSQL, senza dipendere da servizi esclusivi di Lovable Cloud.
Stato attuale
| Componente | Portabile? | Note |
|---|---|---|
| Frontend (React + TanStack Start/Router) | Sì | Build Vite standard, deploy su qualsiasi host Node. |
Server functions / route API (src/routes/api/*) |
Sì | API HTTP standard, nessuna edge function proprietaria. |
| Database | Sì | PostgreSQL puro; lo schema sta nelle migrazioni SQL. |
Client dati (@supabase/supabase-js) |
Sì | Supabase è open source e self-hostable; in alternativa si sostituisce il solo livello dati (src/lib/*.ts). |
Web Push (src/lib/webpush.server.ts) |
Sì | VAPID implementato con Web Crypto, disponibile in Node 18+. |
| Auth | Sì | GoTrue self-hosted oppure qualsiasi provider OIDC. |
src/integrations/lovable/* |
Opzionale | Login social gestito da Lovable: non importato da nessuna schermata, rimovibile senza impatti. |
@lovable.dev/vite-tanstack-config |
Solo build | Preset Vite; sostituibile con una config Vite/TanStack esplicita. |
CMS Strapi (infra/strapi/) |
Sì | Open source e self-hostable, Postgres come backend; l'app lo consuma solo via src/lib/strapi-client.ts. |
Regole da rispettare nelle prossime modifiche
- Nessun accesso al database dai componenti: solo attraverso i moduli in
src/lib/*.ts(palloni.ts,mvp-voti.ts, ...), così il backend è sostituibile in un solo punto. - Nessun uso di funzionalità proprietarie (edge functions Lovable, auth Lovable come unico metodo di login, storage proprietario).
- Configurazione solo via variabili d'ambiente standard
(
DATABASE_URL/SUPABASE_URL+ chiavi,VAPID_*), mai valori hardcoded. - SQL standard PostgreSQL nelle migrazioni: niente estensioni esclusive del provider.
- Job pianificati richiamabili via semplice HTTP POST (es.
/api/public/promemoria-palloni), così funzionano con cron di sistema, pg_cron o qualsiasi scheduler.
Migrazione su server proprio (sintesi)
bun run build(onpm run build) → avvio del server Node generato.- PostgreSQL proprio + applicazione delle migrazioni in
supabase/migrations. - Impostare le variabili d'ambiente (database, chiavi API,
VAPID_*). - Se non si usa Supabase self-hosted: riscrivere solo i moduli dati in
src/lib/con un client Postgres (es.postgres/pg) dentro server functions.