Ruby on Rails 8 sceglie SQLite per il deployment

È stata rilasciato la beta 1 di Ruby on Rails 8.0.0. Questo aggiornamento, reso disponibile in vista della prossima milestone, comprende diverse novità tra cui la più importante è sicuramente la possibilità di utilizzare SQLite in applicazioni Web di produzione. Una feature disponibile sia per il caching che per la scelta del database di riferimento in un progetto.

Questa nuova versione permette di sfruttare SQLite per funzionalità chiave come i job, il caching e i WebSocket, senza la necessità di utilizzare DBMS come MySQL, PostgreSQL e soluzioni in-memory come Redis.

Ruby on Rails 8.0.0 e l'integrazione con SQLite

David Heinemeier Hansson, il creatore di Ruby on Rails, ha ricordato che, in passato, per sfruttare pienamente le funzionalità di Rails era necessario usare appunto MySQL o PostgreSQL e Redis. Ora tutto può essere fatto direttamente con SQLite. Nel corso dell'appuntamento Rails World, Hansson ha confrontato inoltre Redis con SQLite, sottolineando le nuove possibilità offerte da quest'ultimo.

Rails 8.0 introduce tre nuovi adattatori per supportare l'integrazione con SQLite: Solid Cable, Solid Cache e Solid Queue:

• Il primo, per Action Cable, gestisce le comunicazioni in tempo reale tramite WebSocket ed è compatibile anche con MySQL e PostgreSQL.
• Solid Cache è una nuova opzione per la gestione della cache. Esso punta sull'uso degli SSD invece di Redis o Memcached. Permettendo di gestire cache più voluminose.
• Solid Queue è un sistema di gestione delle code di lavoro. Esso viene configurato di default nelle nuove applicazioni Rails 8.0 e supporta anch'esso SQLite, MySQL e PostgreSQL.

Da segnalare che in questa release sono stati inclusi anche il generatore per un sistema di autenticazione e un deployment semplificato grazie a Kamal 2, quindi basato sui container.

SQLite per le applicazioni Web

Fino ad ora SQLite è stato utilizzato nella maggior parte dei casi per applicazioni Desktop ed embedded. Non presenta molte delle funzionalità avanzate dei database server ma per applicazioni Web con traffico medio-basso rappresenta una scelta adeguata. La sua documentazione evidenzia ad esempio che il sito ufficiale del progetto gestisce tra le 400 mila e il mezzo milione di richieste HTTP al giorno, con il 15-20% di esse che coinvolgono il database.