PlyxSQL© SQL Beta 1.0.0.40
POSTED , 12 GIU 2026
Free DOWNLOAD Clicca qui Info https://pgsoft.it/plyxhtml
Chiunque abbia mai dovuto esporre un database esistente tramite API conosce la routine: endpoint CRUD per ogni tabella, paginazione, ordinamento, filtri, CORS, una minima autenticazione, un file di configurazione per le credenziali... lavoro necessario, ma sempre uguale a sé stesso da progetto a progetto.
È proprio questo il problema che il wizard "Genera REST API" di plyxSQL prova a togliere di mezzo. È una finestra integrata nell'IDE, organizzata in tre passaggi, che parte dallo schema del database già letto da plyxSQL e arriva a un progetto backend — e, se vuoi, anche frontend — pronto da compilare. Vediamo come è fatta.
Passo 1 — Tecnologie
La prima pagina del wizard è il centro di controllo del progetto: nome, base URL, porta e cartella di output sono i primi campi che si incontrano, con un comodo selettore di cartelle per l'output.
Subito sotto si scelgono le tecnologie:
- Backend: C++Builder WebBroker o Delphi WebBroker sono già disponibili; una terza opzione, Node.js + Express + TypeScript, in sviluppo. C'è anche la possibilità di non generare alcun backend.
- Tipo di WebModule (solo per i backend RAD Studio): Standalone GUI, Standalone Console, ISAPI DLL, CGI oppure Apache DSO — tutti i principali modelli di deployment di WebBroker. Il wizard suggerisce anche il nome della variabile WebModule seguendo le convenzioni di RAD Studio (ad esempio, da un progetto "Magazzino" propone "MagazzinoWebModule"), così i file generati si integrano senza attriti nel progetto.
- Frontend: Vue 3 + Vite + Pinia è pronto oggi; React + Vite e Angular sono segnati come prossimi arrivi. Anche qui è possibile saltare la generazione del frontend.
- Una checkbox permette di generare anche la documentazione Swagger / OpenAPI 3.0.
La parte finale della pagina è dedicata alla connessione al database, da cui verrà scritto il file configparams.ini usato dal backend generato. Si scelgono driver (Firebird, InterBase, SQL Server, MySQL, PostgreSQL, SQLite, Oracle), host, porta, percorso o nome del database — con un browser file dedicato per i .fdb/.gdb di Firebird — utente e password.
Un dettaglio che vale la pena notare: se nell'albero di plyxSQL è già attiva una connessione al database, il wizard la rileva automaticamente e precompila driver, host, nome database e utente. I campi già personalizzati dall'utente non vengono sovrascritti, e la password — anche se letta dalla connessione attiva — non viene scritta nel file di configurazione a meno che non si spunti esplicitamente l'apposita casella, con un avviso che ne sconsiglia l'uso in produzione.
Passo 2 — Tabelle e colonne
La seconda pagina mostra una griglia con tutte le tabelle dello schema. Con un doppio clic si può:
- attivare o disattivare l'inclusione di una tabella nell'API generata;
- cambiare il ruolo della tabella, che determina cosa viene generato per quella tabella.
I ruoli disponibili sono quattro: Master (CRUD completo), Lookup (solo GET, pensata per alimentare combobox e liste di riferimento), ReadOnly (solo lettura) e WriteThrough (GET più PUT/PATCH sulle colonne scelte, senza creazione o cancellazione). La griglia aggiorna in tempo reale anche una colonna "Note" che spiega in breve cosa comporta il ruolo scelto.
Selezionando una riga, una seconda griglia sotto mostra il dettaglio delle colonne di quella tabella: nome (con un'icona ↻ per i campi auto-incrementanti), tipo formattato con lunghezza o precisione/scala, se è nullable, se è chiave primaria e il valore di default. Le viste SQL (tabelle con prefisso V_ o VW_) vengono riconosciute automaticamente e segnalate come "(Vista SQL)".
Passo 3 — Log di generazione
Premendo "Genera" si passa all'ultima pagina, dove un memo in stile console mostra il log della generazione passo per passo, con un'etichetta di stato che segnala in verde il completamento corretto (o un messaggio diverso se qualcosa è andato storto). Da qui un pulsante "Apri cartella" porta direttamente alla directory di output, pronta per essere aperta nell'IDE.
Perché è comodo
Il punto centrale è che il wizard collassa in pochi minuti una serie di decisioni — tecnologia di backend, tipo di deployment, frontend, database, quali tabelle esporre e con quali permessi — che normalmente richiederebbero ore di codice scritto a mano, identico (o quasi) ad ogni nuovo progetto. Il supporto a più database fin da subito, l'attenzione a piccoli dettagli come la gestione della password o il riconoscimento automatico delle viste, e l'integrazione con le convenzioni di RAD Studio fanno la differenza quando si passa dal prototipo al progetto reale.
Le caselle "prossimamente" per Node.js, React e Angular danno già un'idea della direzione: lo stesso schema, gli stessi ruoli per tabella, ma con output diversi a seconda dello stack scelto.
Backend C++Builder:
Frontend vue.js 3
Nessun commento:
Posta un commento