Lo stack si sceglie sui numeri
PostgreSQL o MongoDB, monolite o microservizi, Node.js o Go: la scelta arriva dopo aver misurato carico, volumi e forma delle interrogazioni.
Architetture software scelte sui numeri del progetto.
Quinck è una software house di Imola, in Emilia-Romagna. Diciannove persone tra ingegneri e designer, società dal 2021 e PMI dal 2026. Progettiamo software su misura, piattaforme dati e IoT e architetture cloud su AWS.
Metà del nostro lavoro è affiancare team che esistono già: prendiamo in carico un modulo per intero, oppure mettiamo un architetto accanto al responsabile tecnico che hai in azienda.
Lo stack si sceglie ogni volta, sui numeri del progetto
TypeScript, React e Next.js sul frontend, Flutter sul mobile, Node.js con Fastify sul backend, Go a bordo macchina quando servono circa 10.000 campioni al secondo. PostgreSQL o MongoDB a seconda del carico, AWS anche serverless con Terraform e pipeline di rilascio automatiche, Modbus e OPC UA per dialogare con i macchinari.
Sperimentiamo dove ha senso e restiamo su tecnologie consolidate dove serve stabilità. Una tecnologia nuova entra in produzione quando regge sotto carico e quando sappiamo mantenerla negli anni.
I microservizi li introduciamo dove il confine fra i domini è chiaro, perché un confine sbagliato si paga per anni. Le scelte che poi costa caro cambiare le prendiamo all'inizio, con i numeri del progetto davanti. Il dettaglio è nelle pagine Cloud e architetture e Dati e IoT.
Sul codice manteniamo test unitari e end-to-end, osservabilità dal primo giorno e una scrittura che chi arriva dopo di noi riesce a leggere senza doverci chiamare.
PERCHÉ NOI
Quattro cose che trovi lavorando con Quinck
Il codice si legge anche fra due anni
Test unitari e end-to-end, osservabilità dal primo giorno, nomi che si spiegano da soli e una pipeline che blocca il rilascio prima degli utenti.
Affianchiamo team che esistono già
Un modulo preso in carico per intero, oppure un architetto accanto al responsabile tecnico che hai in azienda. Metà del nostro lavoro è questo.
Le scelte si discutono
Su un progetto abbiamo valutato PostgreSQL contro MongoDB per tre giorni. Quando una decisione non convince lo diciamo, anche se arriva dal cliente.
Il lavoro, invece della promessa
Sul portfolio tecnico c'è il catalogo dei progetti e delle attività di ricerca e sviluppo, con il dettaglio che serve a chi legge da tecnico: qual era il problema, com'è fatta l'architettura, dove abbiamo sbagliato strada.
Tre schede con le scelte tecniche in chiaro: R&W Tech, IMA e Vernice Italia.
Apri il portfolio tecnico di QuinckAltra roba tecnica da leggere
Su GitHub c'è Multijet, il nostro framework per monorepo a microservizi in TypeScript: dal contratto OpenAPI genera tipi, handler e client. Sul blog scriviamo di problemi che abbiamo avuto davvero, e un socio insegna all'Università di Bologna.
FAQ
Le domande che ci fanno i tecnici
Quanto tempo serve per entrare in un progetto già avviato?
In Quinck entriamo in un progetto avviato leggendo il codice e le pipeline prima di scrivere una riga. Nella prima settimana facciamo girare build, test e ambienti in locale, poi prendiamo in carico un modulo per intero, così il codice nuovo attraversa la stessa pipeline del tuo. Il rilascio resta in mano al tuo team.
Chi scrive materialmente il codice del progetto?
Da noi il codice lo scrive la stessa persona con cui parli in riunione. Siamo 19 a Imola tra ingegneri e designer, e non passiamo il lavoro a filiere di subappalto. Su un progetto lavorano di norma da due a quattro persone, con un riferimento tecnico fisso per tutta la durata.
Con quale criterio scegliete fra PostgreSQL e MongoDB, o fra monolite e microservizi?
Scegliamo la base dati e la forma dell'architettura sui numeri del progetto: volume dei dati, forma delle interrogazioni, carico atteso. Su un progetto abbiamo valutato PostgreSQL e MongoDB per tre giorni prima di decidere. I microservizi li introduciamo dove il confine fra i domini è chiaro, perché un confine sbagliato si paga per anni.
Come leggete i dati dai macchinari industriali?
Leggiamo dai macchinari con Modbus e OPC UA, e usiamo Go a bordo macchina quando la frequenza si avvicina ai 10.000 campioni al secondo. I dati salgono in cloud su AWS con una pipeline che regge le interruzioni di linea e rimette in coda ciò che non è passato. Un esempio è il sistema laser costruito per IMA.
Cosa succede quando qualcosa si rompe in produzione?
Installiamo l'osservabilità dal primo giorno, quindi si parte da log e metriche invece che da ipotesi. Test unitari e end-to-end coprono le regressioni, e la pipeline blocca il rilascio prima che arrivi agli utenti. Quando l'errore è nostro lo diciamo, con la ricostruzione di cosa è successo e di cosa cambiamo.
Cosa si può leggere del vostro codice prima di firmare?
Pubblichiamo su GitHub Multijet, il framework per monorepo a microservizi in TypeScript che dal contratto OpenAPI genera tipi, handler e client. Sul portfolio tecnico ci sono i progetti e le attività di ricerca e sviluppo, con architettura e scelte, e sul blog scriviamo dei problemi che abbiamo incontrato davvero.
Parliamo di codice
Hai un problema tecnico interessante, una scelta di architettura da discutere o un progetto già venduto e ti serve chi lo sviluppi? Ti rispondiamo entro un giorno lavorativo.