Quando il nostro co-fondatore e Engineering Fellow Dmitriy Zaporozhets ha deciso di costruire GitLab, ha scelto di farlo con Ruby on Rails, nonostante all’epoca lavorasse principalmente in PHP. GitHub, una fonte di ispirazione per GitLab, era anche basato su Rails, rendendolo una scelta logica considerando il suo interesse per il framework. Il CEO di GitLab, Sid Sijbrandij, pensa che il suo co-fondatore abbia fatto una buona scelta:
“Ha funzionato molto bene perché l’ecosistema Ruby on Rails ti permette di modellare un sacco di funzionalità ad alta qualità”, ha spiegato. “Se guardate GitLab, ha un’enorme quantità di funzionalità. Lo sviluppo del software è molto complesso e per aiutarlo, abbiamo bisogno di molte funzionalità e Ruby on Rails è un modo per farlo. Poiché ci sono tutte queste best practice che sono sul tuo percorso felice, è anche un modo per mantenere il codice coerente quando spedisci qualcosa come GitLab. Sei in qualche modo guidato a fare la cosa giusta”
Dipendendo dalle gemme utili
Le gemme Ruby giocano un ruolo integrale nella costruzione di GitLab, con il caricamento di più di mille gemme non uniche, secondo Sid. Chiamando il framework Ruby on Rails “molto opinionista”, pensa che sia un ambiente forte in cui costruire un’applicazione complessa come GitLab.
“C’è un grande ecosistema intorno ad esso con gemme che possono fare ipotesi su come stai facendo le cose e a questo proposito, penso che l’ecosistema Ruby on Rails sia ancora senza pari”, dice. “Se guardate il nostro Gemfile, vi dà un’indicazione di quanto sia grande la torre di dipendenze su cui possiamo costruire. Ruby on Rails ha delle spalle incredibili su cui reggersi e sarebbe stato molto più lento sviluppare GitLab in qualsiasi altro framework.”
Superare le sfide
Tutto questo non significa che non ci siano state sfide nel costruire GitLab con Ruby on Rails. Le prestazioni sono state un problema che i nostri sviluppatori hanno fatto passi avanti per migliorare in diversi modi, compresa la riscrittura del codice in Go e l’utilizzo del framework Vue. Quest’ultimo viene utilizzato per riscrivere le pagine di frequente accesso, come i problemi e le richieste di fusione, in modo che si carichino più velocemente, migliorando l’esperienza dell’utente.
Go viene utilizzato per affrontare altri problemi che influenzano i tempi di caricamento e ridurre l’utilizzo della memoria.
“Ruby è stato ottimizzato per lo sviluppatore, non per l’esecuzione in produzione”, dice Sid. “Per le cose che vengono colpite molto e devono essere molto performanti o che, per esempio, devono aspettare molto a lungo su un IO di sistema, le riscriviamo in Go … Stiamo ancora cercando di fare in modo che GitLab usi meno memoria. Quindi, dovremo abilitare il multithreading. Quando abbiamo sviluppato GitLab questo non era comune nell’ecosistema Ruby on Rails. Ora è più comune, ma poiché ora abbiamo così tanto codice e così tante dipendenze, sarà un percorso più lungo per noi per arrivarci. Questo dovrebbe aiutare; non lo renderà incredibilmente veloce, ma almeno userà meno memoria.”
L’aggiunta di Go agli strumenti di GitLab ha portato alla creazione di un servizio separato chiamato Gitaly, che gestisce tutte le richieste Git.
Costruire la missione di GitLab
Lo stile organizzato e strutturato del framework Ruby on Rails è in linea con la nostra missione principale. Poiché Rails è semplificato, chiunque può entrare in GitLab e partecipare, il che ha reso Sid particolarmente attraente fin dall’inizio.
“La nostra missione è che tutti possano contribuire”, spiega. “Poiché Ruby on Rails è molto flessibile per quanto riguarda i pezzi che vanno dove, è molto più facile per i nuovi sviluppatori entrare nella base di codice, perché si sa dove la gente ha messo le cose. Per esempio, in ogni cucina in cui si entra, non si sa mai dove si trovano i coltelli e i piatti. Ma con Ruby on Rails, si entra in cucina ed è sempre nello stesso posto, e vogliamo mantenerlo.
In ogni cucina in cui si entra, non si sa mai dove si trovano i coltelli e i piatti. Ma con Ruby on Rails, entri in cucina ed è sempre nello stesso posto, e vogliamo attenerci a questo.
“Sono stato davvero incoraggiato quando ho aperto il progetto e l’ho visto per la prima volta un anno dopo che Dmitriy lo ha iniziato. L’ho aperto ed è Rails idiomatico. Ha seguito tutti i principi. Non ha cercato di sperimentare qualche tipo di moda a cui era interessato. L’ha trasformato in un’applicazione di produzione. Dmitriy ha controllato attentamente tutti i contributi per assicurarsi che si attengano a quelle convenzioni, e questo è ancora il caso. Penso che abbiamo una base di codice molto bella che permette ad altre persone di costruirci sopra. Uno dei nostri sotto-valori sono le soluzioni noiose: non fare nulla di strano. Questo è così che gli altri possono costruirci sopra. Penso che lo abbiamo fatto davvero bene … e siamo davvero grati che Ruby sia stato un ecosistema così stabile su cui costruire.”
Immagine di copertina di Elvir K su Unsplash
Lascia un commento