Ciao! Sono Joseph, uno studente di informatica a Waterloo, e ho appena concluso uno stage in ingegneria del software presso Slash da settembre a dicembre 2025. Per riassumere brevemente questo blog: mi sono divertito moltissimo e penso che dovresti partecipare anche tu. Grazie per aver letto.
Ok, questa volta sul serio. In passato ho svolto tirocini in diverse aziende, da piccole startup nel settore musicale a grandi aziende tecnologiche, ma Slash mi ha offerto un mix unico di intensità e responsabilità che non avevo trovato altrove. Il team era brillante e affiatato, e ho imparato molto su argomenti complessi, dalla manutenzione di Kubernetes alle prestazioni dei database. Ma soprattutto, ho avuto modo di risolvere alcune sfide davvero interessanti, ed è per questo che ho deciso di scrivere un blog sulle mie esperienze!
Per riassumere brevemente l'attività di Slash, l'azienda ha iniziato come piattaforma finanziaria per imprenditori e rivenditori di scarpe da ginnastica, ma ora è una società fintech bancaria generale che offre carte aziendali, trasferimenti internazionali, conti in criptovaluta e altro ancora. Quando mi sono imbattuto per la prima volta in Slash, non ne sapevo molto. Dopotutto, non sono un appassionato di scarpe da ginnastica, né mi interessavo particolarmente di fintech, quindi ho passato molto tempo a riflettere se valesse la pena cogliere questa opportunità. Tuttavia, come potete intuire da questo post sul blog, la mia scelta di entrare a far parte dell'azienda si è rivelata una delle migliori decisioni che potessi prendere all'inizio della mia carriera.
I motivi principali per cui alla fine ho scelto Slash rispetto alle altre aziende sono stati:
- Era un'azienda di serie B. – Non ho mai lavorato in una startup di queste dimensioni e volevo provare quell'ambiente.
- Il loro fatturato annualizzato era pari a 150 milioni, una cifra incredibilmente alta per un'azienda di serie B. – Non si limitavano a sopravvivere o a resistere; stavano crescendo attivamente. Come bonus aggiuntivo, ciò significava che probabilmente avevano un buon DX e un rigore ingegneristico che molte piccole startup non hanno.
- Stavano crescendo attivamente – Hanno quintuplicato il loro fatturato in un anno e recentemente hanno raccolto fondi per la serie B. Questa azienda era nel pieno del suo periodo d'oro e volevo lavorare in un'azienda che stesse vivendo quel tipo di slancio.
- È un team giovane e pieno di energia. – Dalle mie interviste ho potuto capire che le persone qui erano tranquille e piacevoli con cui parlare. Ero entusiasta di poter lavorare con colleghi con cui potevo relazionarmi.
- È un'azienda piccola e snella. – Ho già detto che questo ARR di 150 milioni è stato realizzato da un team di circa 12 ingegneri? Si tratta di un ARR di 12,5 milioni. per ingegnere, il che è incredibile. È evidente che le persone che lavorano alla Slash sono dei veri talenti, e io avrei sia un'alta quota di proprietà che un ottimo mentore.
- La retribuzione e i vantaggi offerti dalle piccole aziende sono di prim'ordine per gli stage... 🤫
TLDRHo pensato che l'ambiente, le persone di talento e l'energia delle startup avrebbero offerto un luogo incredibile in cui crescere. Ho pensato che avrei avuto la possibilità di occuparmi di un progetto dall'inizio alla fine, dalla creazione dell'infrastruttura alla pianificazione della scalabilità, alla progettazione del sistema e altro ancora, e così ho colto l'occasione!
Progetto: Notifiche V2
Ecco una cosa speciale che ho imparato subito su Slash: assegnano progetti importanti agli stagisti e confidano nella loro capacità di portarli a termine. Nella mia seconda settimana, mi è stato affidato il compito di rinnovare le notifiche di rifiuto delle transazioni con carta. Non sembra così difficile, vero? Tuttavia, il sistema di notifiche esistente presentava alcuni problemi:
- Stretto collegamento con il nostro sistema di eventi interno, con logica aziendale integrata nel nucleo del servizio
- Metriche e-mail scadenti e deliverability ancora peggiore a causa del provider che abbiamo utilizzato
- Esperienza di sviluppo difficile, che ha portato gli ingegneri a bypassare completamente il sistema e richiamare direttamente le API dei provider.
E così arrivò il compito insidioso: per creare email di declino migliori, avevamo bisogno di qualcosa di più di una semplice patch. Avevamo bisogno di un sistema di notifiche completamente riprogettato, e io diventai il DRI per la progettazione, lo sviluppo, il lancio e il ridimensionamento dell'intero progetto. Era un compito davvero intimidatorio... ma anche un'incredibile opportunità per progettare qualcosa che alla fine avrebbe gestito milioni di notifiche. Ero entusiasta di mettermi all'opera.
Dallo studio del precedente sistema di notifica e dalle discussioni con gli ingegneri, ho individuato alcuni principi fondamentali a cui il nuovo sistema dovrebbe attenersi:
- Un design indipendente dall'evento – il servizio dovrebbe funzionare ovunque, sia in script una tantum che in gestori di eventi
- Un design indipendente dal fornitore – La possibilità di rimuovere e introdurre facilmente nuovi fornitori con il minimo sforzo sarebbe impagabile.
- Un design pensato per gli sviluppatori – Niente più frustrazioni. L'esperienza di sviluppo dovrebbe essere il più intuitiva e semplice possibile.
- Osservabile e scalabile - Le notifiche dovrebbero avere un monitoraggio completo del ciclo di vita e dovremmo essere in grado di supportare fino a 3 milioni di e-mail al mese!
Da qui è nato il design basato su handler di Notifications V2. Il sistema è incentrato sui gestori di notifiche, che espongono funzioni handler comuni, come l'invio di notifiche o l'elaborazione di webhook, per specifici provider esterni di canali (ad esempio Resend per le e-mail, Twilio per gli SMS).
Il cuore del sistema è il NotificaIntento, un oggetto transitorio generico utilizzato per trasportare tutti i dati relativi a una notifica, quali provider, canale e argomenti di payload. Ogni gestore definisce la forma dei propri intenti e questi oggetti sono fortemente tipizzati e quindi supportano controlli di tipo statici e introspezione. Ciò significa che gli sviluppatori non devono conoscere tutte le complessità di ciascun provider: possono sfruttare il completamento automatico dell'IDE e fidarsi del fatto che il controllo di tipo li guiderà attraverso il processo.
Per garantire che la logica di business, come il controllo delle preferenze dell'utente, fosse implementata in modo poco accoppiato, una volta che uno sviluppatore chiama una funzione di invio, gli intenti passano attraverso un NotificaMiddleware pipeline prima. I middleware di notifica sono funzioni di ordine superiore che dispongono di una fase di pre-elaborazione per consentire ricerche condivise nel database e di una funzione di elaborazione che ci permette di consentire, trasformare o eliminare gli intenti di notifica. Con questo design, ora possiamo definire diverse funzioni di invio che utilizzano un unico sistema sottostante per definire e condividere la logica di convalida. Ad esempio:
- Possiamo definire una funzione di base "invia notifica" che ha intenti che fluiscono attraverso un
DestinatarioBannatomiddleware, che elimina gli intenti se le informazioni del destinatario (e-mail, numero di telefono) sono presenti in una lista di blocco personalizzata - Possiamo definire una funzione "invia all'utente" più complessa che abbia flussi di intenti attraverso lo stesso
DestinatarioBannatomiddleware e unRispetta le preferenze dell'utentemiddleware, che elimina gli intenti se l'utente ha disattivato le notifiche su quel canale
Come ulteriore vantaggio, i futuri sviluppatori potranno facilmente aggiungere, rimuovere o modificare nuove funzioni di invio senza dover rintracciare un labirinto di funzioni.
Dopo la fase di middleware, il servizio crea Notifica oggetti del ciclo di vita prima di avviare un flusso di lavoro Temporal. Temporal è ottimo perché ci offre tentativi di riprova integrati per gli errori del flusso di lavoro, uno stato durevole e garanzie di orchestrazione. Tutti questi aspetti sono importanti per garantire la consegna delle notifiche. Il flusso di lavoro mette in coda le notifiche, limita gli invii per rispettare i limiti di velocità del provider e quindi non inviare spam agli utenti, quindi passa i batch ai gestori del provider. I gestori si assumono quindi la responsabilità di inviare la notifica al provider e il servizio aggiorna il ciclo di vita di conseguenza.
Una volta che un provider esterno ci invia una risposta webhook, gli handler la convertono in un tipo di dati standardizzato ed emettono azioni tipizzate. Le azioni ci offrono un modo strutturato e sicuro dal punto di vista del tipo per rispondere agli eventi quando riceviamo una notifica, mantenendo il servizio il più possibile neutrale. Ad esempio,
- Abbiamo un'azione per l'aggiornamento dei destinatari: in questo modo, gli operatori possono aggiornare i destinatari come "bannati in modo permanente" o meno, a seconda di ciò che il provider e il canale determinano come "bannato".
- Abbiamo un'azione per riprovare una notifica: ad esempio, se un'e-mail viene temporaneamente respinta, vogliamo riprovare a inviarla in modo esponenziale. Se il gestore determina che la risposta del provider di posta elettronica è stata "respinta", può attivare questa azione.
Uff! Questo è più o meno tutto. Lungo il percorso, ho incontrato diverse altre sfide ingegneristiche interessanti, come
- Supporto dei tentativi esponenziali: pianifichiamo i futuri tentativi all'interno di Temporal in base al numero di tentativi già effettuati.
- Buona tracciabilità – Ad esempio, memorizziamo gli ID di tracciamento, così come le notifiche e i relativi tentativi, in un
Set di notificheentità - Invio in batch: l'integrazione dell'invio individuale e in batch ci consente di evitare il superamento dei limiti di velocità imposti dai provider e offre agli sviluppatori il controllo sulle modalità di invio delle notifiche.
Lascerò che siano i potenziali nuovi ingegneri a scoprire i dettagli nel codice, una volta entrati a far parte del team 😉
Progetto: Rinnovamento
Il progetto Facelift è stata la riprogettazione completa dell'esperienza web di Slash da parte del nostro team (vedi il blog eng qui da Albert Tian, il padre del lifting facciale). Non mi addentrerò troppo nei dettagli di Facelift (anche in questo caso, vi rimando al fantastico blog degli ingegneri), ma in sostanza si trattava di introdurre una nuova libreria di componenti + Tailwind nel nostro enorme frontend. Per prepararsi al lancio, il team di ingegneri ha deciso di divertirsi un po' e organizzare una hackweek mirata! Non si è trattato però della tipica hackweek in ufficio: siamo saliti su un paio di auto, abbiamo guidato per tre ore fino a una baita sul Bass Lake, vicino allo Yosemite, e abbiamo trascorso la settimana costruendo, rifattorizzando e divertendoci davvero insieme.
Durante questa settimana, sono passato completamente dal lavoro di backend all'aiuto nel rinnovamento delle transazioni e dei flussi di controversie. Si trattava principalmente di lavoro di frontend, il che ha rappresentato un cambiamento di ritmo rinfrescante rispetto al mio lavoro precedente e mi ha anche permesso di lavorare su gran parte della nostra infrastruttura di progettazione frontend, come ad esempio:
- Primitive fondamentali: ad esempio, come generiamo i nostri pannelli laterali, i modali e i popup
- Componenti componibili riutilizzabili: ad esempio,
Ricerca selezionabile - Responsabile tabella: il nostro componente personalizzato per creare tabelle con funzioni di ordinamento, filtraggio, impaginazione e ricerca facili da usare.
- Robusta convalida dei sottomoduli: utilizzando Arktype, i moduli Tanstack e il nostro sistema di generazione di modelli
Il facelifting non riguardava tanto la complessa logica del prodotto, quanto piuttosto la possibilità di vedere quanto velocemente il nostro team può muoversi quando è concentrato e allineato su un progetto collettivo. Vedere l'intero sito trasformarsi nel corso della settimana, insieme alla costruzione e al legame con i miei colleghi in quella cabina, è stato sicuramente uno dei momenti salienti del mio tirocinio. Il lavoro di facelift non è finito quella settimana, però: nelle due settimane successive ci siamo assicurati che il lancio avvenisse senza intoppi, collaborando con il supporto per eliminare ogni minimo difetto del prodotto!
Progetto: Modelli
Alla fine di ogni semestre, la mia università invia un breve modulo con una semplice domanda: "Quanto sono stati utili i corsi che hai seguito per il tuo lavoro?". Beh, durante il mio periodo presso Slash, ho potuto applicare direttamente alcuni concetti appresi in classe! Volevamo che le nostre e-mail transazionali fossero in linea con il nostro nuovo design Facelift, quindi era logico che il nostro sistema di notifiche supportasse modelli personalizzati. Per garantire l'utilizzo degli stessi colori e spaziature del nostro frontend, abbiamo finito per creare questi modelli in codice utilizzando React Email, una libreria di modelli di email che ci ha permesso di utilizzare JSX per questi modelli. Questa soluzione era perfetta per noi: dato che il nostro team conosce molto bene React JSX, abbiamo potuto garantire la coerenza del marchio utilizzando lo stesso sistema di progettazione Tailwind CSS v4 sia per il web che per le email.
Tuttavia, c'era un inconveniente: uno dei vantaggi principali di TailwindCSS 4 è la possibilità di utilizzare file CSS personalizzati invece del tradizionale oggetto di configurazione JS, che il nostro team ha sfruttato. Tuttavia, il componente Tailwind di React Email in realtà richiesto l'oggetto di configurazione JS.
Questo significava che dovevo costruire un transpiler!
Per descriverlo in modo più preciso, durante la fase di compilazione ho aggiunto uno script per creare un albero sintattico astratto (AST) dai file CSS del sistema di progettazione. Questo AST ha fornito una rappresentazione strutturata delle regole CSS e mi ha permesso di analizzare facilmente il file per:
- Filtra le classi CSS non supportate: ad esempio, gli stili al passaggio del mouse e le utilità del puntatore non funzionano nella maggior parte dei client di posta elettronica.
- Converti in un sistema di colori compatibileAbbiamo utilizzato OKLCH per definire i nostri colori, ma i client di posta elettronica non sono in grado di visualizzarli, quindi questi vengono convertiti in HEX.
- Crea l'oggetto di configurazione TS: Questo viene compilato in JS e può quindi essere facilmente importato in qualsiasi punto del codice.
Questa fase di transpilazione è stata un modo rapido per implementare un'unica fonte di verità per il nostro sistema di progettazione. Se un colore veniva modificato, sarebbe stato coerente su tutti i nostri mezzi di comunicazione - web o e-mail - poiché sarebbe stato immediatamente transpilato una volta ricostruito. Inoltre, altri client, come la nostra applicazione mobile, potevano utilizzare questo oggetto transpilato secondo necessità. Con l'oggetto di configurazione generato, sono stato in grado di creare una serie di componenti React comuni per le nostre e-mail che rispecchiavano i nostri componenti web, come Tipografia e Pulsante componenti, con elementi quasi identici. Tutto ciò ha contribuito a migliorare l'esperienza degli sviluppatori, rendendo la creazione di modelli meno laboriosa!
Infine, ho anche creato dei modelli di notifica che sfruttano il nostro framework di registrazione interno, una struttura dati personalizzata che abbiamo creato (vedi questo post sul blog). In breve, i registri ci offrono un modo sicuro dal punto di vista tipografico per definire modelli, serializzarli e deserializzarli dal database e mantenere insieme la logica di business definita. Ad esempio, il autorizzazione-carta.modello-notifica.tsx si trova proprio accanto al codice del gestore di eventi di autorizzazione delle carte, il che è ottimo per vedere rapidamente quali eventi hanno notifiche! È stato fantastico poter utilizzare i registri in questo progetto: ha davvero dimostrato l'impegno del team nel scrivere codice valido e riutilizzabile.
Cosa ho imparato?
Sono arrivato pensando che sarebbe stata un'esperienza unica e sono felice di aver deciso di partecipare: Slash mi ha insegnato più di qualsiasi altro ruolo che ho ricoperto in passato in materia di proprietà, progettazione di piattaforme e velocità di ingegnerizzazione. Alcuni dei punti chiave che ho appreso sono stati:
- La fiducia è inestimabile – Slash non prevede riunioni quotidiane. Slash non prevede sprint settimanali né backlog grooming. Abbiamo una riunione a settimana, che serve solo a mostrare al team intero ciò che abbiamo realizzato. Questo funziona perché il team nel complesso ha una forte comunicazione e notevoli capacità di ownership. Ciò non significa che non ci sia mentorship: ho incontri individuali settimanali per sbloccare me stesso, ma piuttosto che Slash si fida di te e ti permette di dare il meglio di te, coltivando un ambiente in cui puoi concentrarti il più possibile.
- La squadra è incredibile – Nelle altre cooperative in cui ho lavorato, i miei colleghi erano professionali, ma qui i miei colleghi erano la mia genteÈ chiaro che Slash ha una cultura fantastica, con persone divertenti, disponibili e con cui è facile lavorare: non c'era una sola persona con cui non mi piacesse lavorare o che mi intimidisse, e ti trattano proprio come un dipendente a tempo pieno. Inoltre, nei fine settimana puoi andare a giocare a basket con loro 😃
- Come stagista, qui crescerai in modo esponenziale rispetto a qualsiasi altro posto. – In qualsiasi altra azienda, allo stagista non sarebbe stato affidato l'intero sistema di notifica centrale come progetto. I problemi difficili e stimolanti sarebbero stati risolti o sarebbero stati risolti da qualche ingegnere senior. Ciò che rende Slash unica è la combinazione di team snelli, problemi reali e critici per l'azienda e una cultura che affida anche agli stagisti lavori importanti.
Ecco alcuni altri ricordi divertenti di questo tirocinio:
- Abbiamo mangiato circa 9 kg di bistecche in una settimana... grazie Hack Week!
- Ho battuto il mio collega stagista in una partita a biliardo e subito dopo sono stato umiliato da un dipendente a tempo pieno.
- Finalmente sono riuscito a sollevare un disco!
- Sono uno dei principali responsabili della "gola diffusa in ufficio" (e, cosa potenzialmente correlata, ho scoperto di amare Shake Shack).
Questi quattro mesi sono volati più velocemente di quanto mi aspettassi e sono grato per l'esperienza che ho vissuto presso Slash. Presto mi laureerò e, indipendentemente da ciò che mi riserverà la vita tra un mese, un anno o un decennio, so che il tirocinio presso Slash mi ha fornito le competenze e la sicurezza necessarie per avere successo ovunque andrò.
Se sei interessato a saperne di più, Non esitare a contattarmi su LinkedIn! Sarò lieto di rispondere a qualsiasi domanda tu possa avere.