Questo è il secondo articolo di Omar.log(). Se hai perso il primo, ho pubblicato la tesi che ho scritto nel 2022 su Learnn dopo averla tenuta su una mensola per anni.
In quell’articolo avevo anticipato che avrei scritto di cosa rifarei e cosa no, riguardando tutto con la prospettiva di oggi. Questo è il primo dei due: le 5 scelte che rifarei identiche.
Non sono le scelte tecnologicamente più eleganti. Sono quelle che ci hanno permesso di muoverci velocemente in una fase in cui la velocità di esecuzione era tutto. Alcune le rifarei per i motivi per cui le abbiamo fatte allora, altre le rifarei per motivi che ho capito solo col tempo.
I requisiti erano chiari: una dashboard per il team per caricare i contenuti e un sistema per gestire utenze e contenuti. Le opzioni sul tavolo erano due: costruirci tutto noi — dashboard, API, autenticazione — oppure fare “buy” e valutare soluzioni esistenti.
Abbiamo scelto Strapi.
All’epoca era la versione 3, non esisteva ancora Strapi Cloud. Lo abbiamo hostato su una macchina EC2 su AWS. Con il tempo, dopo la migrazione a Strapi V4 e il nuovo layer DB, lo abbiamo portato su ECS per avere anche scalabilità orizzontale.
Si è rivelata un’ottima scelta per una serie di motivi. Gestiva già tutto il flusso di autenticazione: API pronte per signup e login, sistema di permessi e ruoli built-in , cosa che si sarebbe rivelata fondamentale poi per il modello freemium. Lato contenuti offriva sia REST che GraphQL e gli schema erano semplici da definire. Lato integrazione con AWS aveva già un plugin ufficiale per caricare i media su S3.
La decisione di avere un monolite iniziale con auth e contenuti insieme è stata vincente. Il sistema era up and running nel giro di un paio di settimane, e questo ci ha permesso di rilasciare la prima versione dell’app in 45 giorni.
Se avessimo deciso di sviluppare una dashboard proprietaria e di mettere su un server con le nostre API ci avremmo impiegato molto più tempo. E sarebbe stato tutto da manutenere.
Oggi ci sono più alternative sul mercato, ma il principio resta lo stesso: in fase iniziale, nel dilemma “make or buy”, il buy batte il make quasi sempre. Il tempo che risparmi lo investi in quello che ti differenzia davvero.
Nella tesi (cap. 2.1) racconto il passaggio da Waterfall ad Agile. Ma quello che non racconto è quanto lo slicing verticale abbia cambiato il modo in cui lavoravamo.
La metodologia Agile con sprint settimanali ci ha permesso di iterare velocemente avendo dei deliverable ogni settimana. In una fase in cui la velocità di esecuzione era tutto si è rivelata fondamentale. Ci ha aiutato anche a scegliere di volta in volta quali feature dovevano finire nell’MVP e quali potevano aspettare. Il ragionare a incrementi è una filosofia che mi porto dietro tutt’ora.
Inizialmente siamo partiti facendo slicing orizzontale: dividevamo i task delle user stories in frontend e backend, sviluppati da persone diverse. Poi siamo passati allo slicing verticale.
Per chi non conoscesse il termine: slicing verticale vuol dire creare PBI e user stories non dividendo in frontend e backend, ma ragionando per feature end-to-end. Ogni sviluppatore prende una feature e la porta a termine, da database a interfaccia.
È molto più difficile perché tutti devono avere competenze sia frontend che backend. Ma evita i rallentamenti tipici di quando lo sviluppatore frontend deve aspettare che il backend aggiunga un’API. Si potrebbe fare un mock, ma è macchinoso e aggiunge complessità.
Anche oggi in Learnn facciamo continuamente slicing verticale. È una di quelle scelte che una volta fatte non torni più indietro.
Date le dimensioni del team (inizialmente 2 persone) sarebbe stato impossibile manutenere due app native. React Native con una sola codebase fa build sia per iOS che per Android, e per noi era l’unica strada percorribile.
Non nego che negli anni ci ho dovuto sbattere molto la testa: incompatibilità tra moduli, problemi di release dopo gli aggiornamenti, debug complicato. Io ho iniziato a sviluppare con React Native nel 2018, quando c’era ancora la versione 0.50 e ogni volta che preparavi un pacchetto dovevi accendere un cero.
C’è da dire che negli ultimi anni l’ecosistema ha fatto passi da gigante ed è supportato da una community molto attiva. (vedi expo).
E la velocità che ci ha dato avere un’unica codebase era insostituibile per un team della nostra dimensione.
Sul fatto di partire sviluppando un’app mobile prima ancora della web app, e sulla manutenzione che ne consegue, avrei da ridire. Ma ne parlerò nel prossimo articolo…
Ne ho parlato sia nei post LinkedIn che nella tesi (cap. 3.2): la separazione tra contenuti statici su Strapi e progressi utente su DynamoDB con tre tabelle denormalizzate.
Il dettaglio completo lo trovi nella tesi.
La ridondanza dei dati è stato un tradeoff giusto. Avere lo stesso dato in più posti va contro qualsiasi manuale di database design, ma la velocità di lettura che ci ha dato giustificava tutto.
La cosa interessante è che questa struttura è ancora in produzione oggi. Non siamo passati a un’architettura ad eventi perché lato prodotto non ne avevamo bisogno. Abbiamo fatto dei POC per funzionalità come gamification e statistiche avanzate, ma dato che non sono utili al prodotto in questo momento non sono in produzione.
Questo mi ricorda quanto sia importante non soffermarsi solo sulla tecnologia e l’architettura perfetta ma partire dalle reali necessità per poi valutare le soluzioni. Spesso l’architettura perfetta non è la soluzione migliore.
Questa non è una scelta tecnica in senso stretto, ma è la scelta che ha guidato tutte le altre.
Dopo la validazione con Mighty Networks, prima di buttarci a sviluppare l’app proprietaria, abbiamo somministrato un questionario ai 4.500 utenti iscritti. 332 risposte. Gli abbiamo chiesto quali funzionalità si aspettavano, come avrebbero usato l’app, cosa non funzionava nell’esperienza attuale.
Quel sondaggio è stata una miniera d’oro. Ci ha fatto capire qual era la frizione che gli utenti avevano nell’utilizzo della piattaforma su Mighty Networks. Ci ha permesso di stilare la prima lista di funzionalità di fruizione che poi abbiamo integrato nella roadmap. Nella tesi ci sono i risultati nel dettaglio.
Anche oggi, se dovessi validare nuovamente o lanciare qualcosa, partirei da user interviews e sondaggi. Prima capisci il problema, poi costruisci la soluzione. Sembra ovvio ma la tentazione di saltare questo passaggio è fortissima, soprattutto quando hai competenze tecniche e la voglia di iniziare a scrivere codice.
Rileggendo queste 5 scelte mi rendo conto che il filo conduttore non è la tecnologia specifica. Strapi potrebbe essere sostituito da qualcos’altro, React Native potrebbe essere Flutter, DynamoDB potrebbe essere un altro database.
Il pattern è un altro: in ogni caso abbiamo scelto la soluzione che ci faceva andare più veloci nel breve termine accettando tradeoff consapevoli. Monolite invece di microservizi. Ridondanza invece di normalizzazione. Buy invece di make. Un framework cross-platform invece di due app native.
Non erano le scelte perfette. Erano le scelte giuste per la fase in cui eravamo.
Nel prossimo articolo ti racconto le 5 scelte che non rifarei mai più.
Omar
Se questo articolo ti è stato utile, condividi Omar.log() con qualcuno a cui potrebbe servire 👇
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.