Rails è un framework compatibile con Rack e incentrato sullo sviluppo rapido di applicazioni. Purtroppo, l'approccio "tutto fuori dalla scatola" e il comportamento cieco del Rails-way spesso fanno perdere qualità al codice dell'applicazione, sia in termini di ricezione (leggibilità) che di funzionamento.
Problemi popolari di Rails e Rails-way
- routing,
- prima delle azioni,
- grandi azioni nei controllori,
- metodi privati nei controllori,
- mixin utilizzati una sola volta,
- logica nelle viste,
- Richiami di ActiveRecord,
- Associazioni,
- "modelli grassi".
Problemi aggiuntivi
- Convalida dei record attivi,
- implicita rispetto a quella esplicita,
- abuso di DRY,
- deleghe alle associazioni,
- chiamate di servizio nei modelli.
Alternative a Rails
Quando si tratta di Rotaie nel Rubino mondo, abbiamo diverse alternative. Altri framework basati su Rack sono: - Sinatra, – Roda, – Hanami.
Cosa li rende unici?
Sia Sinatra che Roda ci offrono una sintassi di routing a blocchi, ma il routing in Sinatra è un elenco e in Roda un albero. In entrambi i framework, dobbiamo occuparci noi stessi dell'implementazione del livello del modello. Nel caso di Roda, è una buona idea utilizzare la gemma Sequel.
Roda è ispirato a Sinatra. È molto leggero di per sé, ma ha molti plugin.
L'Hanami è il momento più vicino a Rotaie per quanto riguarda le aree coperte dal quadro normativo. Le differenze più importanti in termini di utilizzo sono:
- controllori in Rotaie contro le azioni nell'Hanami,
- classi/oggetti dedicati che gestiscono una specifica richiesta HTTP, non un controllore per le azioni relative a una specifica risorsa (modello),
- basato su repository ed entità, separando la persistenza dal resto dell'applicazione, non il modello di record attivo.
La versione 1 di Hanami limita fortemente l'uso della ROM su cui si basa (versione 3 e già 5), quindi non vale la pena utilizzare il livello di modello proposto. Tuttavia, trattandosi di un framework molto aperto, è abbastanza facile implementarvi il proprio modello.
Supplementi per Rails
Vale la pena di utilizzare soluzioni che non dipendono da Rotaie e sono più vicini a quelli "puri" Rubino. Gli strumenti citati nella presentazione sono:
- Sequel (ORM, alternativa ad ActiveRecord),
- ROM (mappatore di oggetti),
- librerie dry-rb: dry-validations, dry-system e dry-monads.
Il sequel è facile da inserire in un progettoè basato su plugin e implementa anche lo schema dei record attivi. Ha un supporto migliore per le query di basso livello rispetto a Rotaie' ActiveRecord.
ROM utilizza Sequel, ma il suo concetto è quello di tradurre tra i record del database e quelli del database. Rubino oggetti. Mira alla velocità e alla trasformazione dei dati. Separa chiaramente il livello di persistenza nell'applicazione.
Le librerie Dry-rb sono strumenti molto utili:
- La convalida a secco è molto facile da usare nei progetti API e consente un grande controllo sulla correttezza dei dati in entrata,
- dry-system richiede un po' di pratica e di pazienza da parte degli sviluppatori per essere compreso, ma permette una gestione molto flessibile delle dipendenze nell'applicazione e il caricamento di componenti del progetto in modo isolato; se vogliamo utilizzare questa libreria in Rotaie, possiamo usare i binari a secco,
- dry-monads è un concetto difficile in teoria, ma in pratica è più facile da capire, il risultato monadi può essere un ottimo modo per aumentare la leggibilità di codice considerando casi specifici invece di ramificare gli if.
Conclusioni
È meglio usare Rotaie in modo da non dover usare Rotaie un giorno.
Fonti
Articoli
Quadri
Gemme
Specifiche tecniche
Per saperne di più:
Che cos'è Ruby on Jets e come si costruisce un'applicazione utilizzandolo?
Vuelendar. Un nuovo progetto di Codest basato su Vue.js
Il rapporto settimanale di Codest sui migliori articoli tecnologici. Creare software per 50 milioni di socket simultanei (10)