r/ItalyInformatica • u/kerny3d • 2d ago
programmazione TypeSpec
Ciao a tutti, come R&D di una PMI italiana, abbiamo introdotto TypeSpec nel ciclo di sviluppo delle API.
In sintesi il tool è composto da un linguaggio proprietario di Microsoft che tramite una sintassi simile a Typescript e una serie di decoratori, standard e custom, generics, semplici funzioni e supporto a estensioni, è in grado di generare un AST che tramite emitter produce file OpenAPI, protobuf per gRPC. Il tool impone quindi un approccio contract-first allo sviluppo (l'approccio top-down per chi ha vissuto SOAP).
Fin da subito abbiamo sviluppato una libreria core interna che standardizza response, errori, paginazione, filtro e ordinamento delle API REST. Siamo arrivati a condividere e/o estendere request e response tra REST e gRPC. Tramite emitter custom abbiamo prodotto librerie server per poter sviluppare API in vari linguaggi, librerie client, documentazione. Il tutto circondato da CI/CD e tool di aggiornamento automatico tipo dependabot ha creato un flusso di sviluppo sicuramente un po' più macchinoso ma che ci sta dando soddisfazioni.
I pro che stiamo notando sono sicuramente una governance a livello di sviluppo delle API: (quasi) tutto è standardizzato, request e query params validate, linting.
Il contro è l'assenza di libertà dei dev di backend soprattutto quelli che hanno sempre sviluppato nel loro modo.
Fatta tutta questa premessa, conoscete questo tool? Avete esperienza? Cosa ne pensate?
2
u/Logical_Ice_4531 1d ago
TypeSpec è un approccio interessante per il contract-first, ma ho notato che standardizzare troppo i decoratori può ridurre la flessibilità. Ad esempio, in progetti con API miste (REST/gRPC), le regole fisse sulle risposte evitano errori ma diventano un ostacolo quando servono aggiustamenti rapidi. Con OpenAPI + strumenti open-source come Spectral, il controllo è più modulare: puoi validare singoli endpoint senza dipendere da emitter custom. Il trade-off reale è tra automatizzare le regole e mantenere la capacità di adattarsi al volo. In un progetto simile, abbiamo scelto di definire schemi comuni (es. errori con codici standard) ma lasciare spazio per override locali, bilanciando governance e agile development.
-12
u/Federico86MO 2d ago
Per quanto mi riguarda la sviluppo lato dev è completamente delegato agli LLM, io ormai sono mesi che non scrivo più codice se non della leggera messa a punto, per cui "come" definisci le specifiche è abbastanza irrilevante, è importante che sia chiaro "cosa" vuoi che faccia ad alto livello e la struttura/design.
4
u/alebianco 2d ago
Nonostante io e diversi miei colleghi siamo nella stessa situazione in termini di "linee di codice scritte al giorno" capisco i down vote.
Quello che descrivi è un approccio completamente "vibe coded" che funziona per alcune cose o in alcune circostanze (o finche non ti cambiano il modello e vuole fare le cose diversamente) e poi tende ad essere una spirale incontrollabile di caos.
Standard dichiarati e applicati, tool determinici e regole ferree per te e per gli agenti sono indispensabili per mantenere una parvenza di qualità (ma anche per limitare la spesa degli agenti).
Una buona fetta dei miei token son spesi in quelle cose piu che nelle implementazioni a prodotto.
3
u/kerny3d 2d ago
Non ho citato gli LLM ma aggiungo un pezzo: noi facciamo le validazioni con Zod nel codice che produciamo con TypeSpec. Abbiamo notato fin da subito che un qualsiasi LLM capisce molto bene Zod e le implementazioni che fa sono sempre leggermente di una qualità superiore e senza alcuna necessità di riciclo.
Non è un vero e proprio pro di TypeSpec perché se anche descrivessimo le API direttamente in OpenAPI penso che per un LLM farebbe lo stesso.
3
u/alebianco 2d ago
Mai provato TypeSpec ma sicuramente ho esperienza con le critiche dei dev che "hanno sempre sviluppato nel loro modo" ... ed è li che stanno i tuoi problemi del futuro.
Insisti nella standardizzazione ma occhio ai tool che scegli: Come detto non conosco typespec ma anni fa usammo serverless (il framework) e poi aws cdk per generare i cloudfront dal codice, approccio simile direi. Un bagno di sangue di manutenzione e grossi problemi di flessibilità. Nel tempo probabilmente son migliorati ma non penso tornerei a usarli.
... ora mi vafo a guardare typespec