Ciao! Sono

Federico Calò

Sviluppatore Software | Divulgatore Tecnico

Creo applicazioni web moderne e strumenti digitali personalizzati per aiutare le attività a crescere attraverso l'innovazione tecnologica. La mia passione è unire informatica ed economia per generare valore reale.

Contattami

Chi Sono

La mia passione per l'informatica è nata tra i banchi dell'Istituto Tecnico Commerciale di Maglie, dove ho scoperto il potere della programmazione e il fascino di creare soluzioni digitali. Fin da subito, ho capito che l'informatica non era solo codice, ma uno strumento straordinario per trasformare idee in realtà.

Durante gli studi superiori in Sistemi Informativi Aziendali, ho iniziato a intrecciare informatica ed economia, comprendendo come la tecnologia possa essere il motore della crescita per qualsiasi attività. Questa visione mi ha accompagnato all'Università degli Studi di Bari, dove ho conseguito la Laurea in Informatica, approfondendo le mie competenze tecniche e la mia passione per lo sviluppo software.

Oggi metto questa esperienza al servizio di imprese, professionisti e startup, creando soluzioni digitali su misura che automatizzano processi, ottimizzano risorse e aprono nuove opportunità di business. Perché la vera innovazione inizia quando la tecnologia incontra le esigenze reali delle persone.

Le Mie Competenze

Analisi Dati & Modelli Previsionali

Trasformo i dati in insights strategici con analisi approfondite e modelli predittivi per decisioni informate

Automazione Processi

Creo strumenti personalizzati che automatizzano operazioni ripetitive e liberano tempo per attività a valore aggiunto

Sistemi Custom

Sviluppo sistemi software su misura, dalle integrazioni tra piattaforme alle dashboard personalizzate

const federico = {
  nome: "Federico Calò",
  ruolo: "Sviluppatore Software",
  città: "Bari, Italia",
  missione: "Aiutare attraverso l'informatica",
  passioni: [
    "Codice Pulito",
    "Innovazione",
    "Crescita Continua"
  ]
};

La Mia Missione

Credo fermamente che l'informatica sia lo strumento più potente per trasformare le idee in realtà e migliorare la vita delle persone.

🚀

Democratizzare la Tecnologia

La mia missione è rendere l'informatica accessibile a tutti: dalle piccole imprese locali alle startup innovative, fino ai professionisti che vogliono digitalizzare la propria attività. Ogni realtà merita di sfruttare le potenzialità del digitale.

💡

Unire Informatica ed Economia

Non è solo questione di scrivere codice: è capire come la tecnologia possa generare valore reale. Intrecciando competenze informatiche e visione economica, aiuto le attività a crescere, ottimizzare processi e raggiungere nuovi traguardi di efficienza e redditività.

🎯

Creare Soluzioni su Misura

Ogni attività è unica, e così devono esserlo le soluzioni. Sviluppo strumenti personalizzati che rispondono alle esigenze specifiche di ciascun cliente, automatizzando processi ripetitivi e liberando tempo per ciò che conta davvero: far crescere il business.

Trasforma la Tua Attività con la Tecnologia

Dicembre 2024

Visualizza

Master SQL

RoadMap.sh

Novembre 2024

Visualizza

Oracle Certified Foundations Associate

Oracle

Ottobre 2024

Visualizza

People Leadership Credential

Connect

Settembre 2024

💻 Linguaggi & Tecnologie

☕Java

🐍Python

📜JavaScript

🅰️Angular

⚛️React

🔷TypeScript

🗄️SQL

🐘PHP

🎨CSS/SCSS

🔧Node.js

🐳Docker

🌿Git

💼

12/2024 - Presente

Custom Software Engineering Analyst

Accenture

Bari, Puglia, Italia · Ibrida Analisi e sviluppo di sistemi informatici attraverso l'utilizzo di Java e Quarkus in Health and Public Sector. Formazione continua su tecnologie moderne per la creazione di soluzioni software personalizzate ed efficienti e sugli agenti.

💼

06/2022 - 12/2024

Analista software e Back End Developer Associate Consultant

Links Management and Technology SpA

Esperienza nell'analisi di sistemi software as-is e flussi ETL utilizzando PowerCenter. Formazione completata su Spring Boot per lo sviluppo di applicazioni backend moderne e scalabili. Sviluppatore Backend specializzato in Spring Boot, con esperienza in progettazione di database, analisi, sviluppo e testing dei task assegnati.

💼

02/2021 - 10/2021

Programmatore software

Adesso.it (prima era WebScience srl)

Esperienza nell'analisi AS-IS e TO-BE, evoluzioni SEO ed evoluzioni website per migliorare le performance e l'engagement degli utenti.

🎓

2018 - 2025

Laurea in Informatica

Università degli Studi di Bari Aldo Moro

Bachelor's degree in Computer Science, focusing on software engineering, algorithms, and modern development practices.

📚

2013 - 2018

Diploma - Sistemi Informativi Aziendali

Istituto Tecnico Commerciale di Maglie

Technical diploma specializing in Business Information Systems, combining IT knowledge with business management.

Contattami

Hai un progetto in mente? Parliamone! Compila il form qui sotto e ti risponderò al più presto.

* Campi obbligatori. I tuoi dati saranno utilizzati solo per rispondere alla tua richiesta.

Il Panorama delle API nel 2026: REST, GraphQL, gRPC, tRPC — Quando Usare Cosa

Stai iniziando un nuovo progetto e devi scegliere il protocollo API. REST? GraphQL? gRPC? tRPC? La risposta giusta nel 2026 non e "il piu moderno" o "quello che tutti usano", ma dipende da fattori concreti: il tipo di client (pubblico vs interno), i requisiti di latenza, le competenze del team, e il contesto dell'applicazione.

Questa panoramica costruisce una matrice decisionale pratica basata su dati reali: REST appare nel 70% delle offerte di lavoro backend, GraphQL e in calo al 25% (da 32% nel 2023) dopo anni di hype, tRPC cresce al 15% nei ruoli TypeScript, e gRPC domina le comunicazioni service-to-service nei microservizi. Capire perche questi numeri esistono ti aiuta a fare la scelta giusta.

Cosa Imparerai

Caratteristiche fondamentali di REST, GraphQL, gRPC e tRPC
Matrice decisionale: quale protocollo per quale scenario
Dati di adozione 2026 e tendenze di mercato
Trade-off reali di ogni approccio
Come combinare piu protocolli nella stessa architettura
Checklist per la scelta del protocollo API

I Quattro Protocolli: Overview Rapida

Prima di approfondire la matrice decisionale, definiamo precisamente cosa fa ciascun protocollo:

REST (Representational State Transfer)

REST e un'architettura, non un protocollo. Si basa su HTTP standard con URL come risorse, verbi HTTP (GET, POST, PUT, DELETE) come azioni, e JSON come formato di payload predominante. REST non ha uno schema di tipo formale (OpenAPI e uno standard de facto, non parte del REST originale), non ha un linguaggio di query, e ogni endpoint espone una risorsa specifica.

// REST: ogni risorsa ha il suo endpoint
GET    /api/v1/users           -> lista utenti
GET    /api/v1/users/123       -> utente specifico
POST   /api/v1/users           -> crea utente
PUT    /api/v1/users/123       -> aggiorna utente
DELETE /api/v1/users/123       -> elimina utente
GET    /api/v1/users/123/orders -> ordini dell'utente

GraphQL

GraphQL e un linguaggio di query per API dove il client specifica esattamente i dati che vuole. C'e un unico endpoint (di solito POST /graphql), e il client invia una query che descrive la struttura dei dati richiesti. Lo schema e il contratto formale e tipizzato.

// GraphQL: il client decide esattamente cosa ricevere
query {
  user(id: "123") {
    name
    email
    orders(last: 5) {
      id
      total
      status
    }
  }
}

gRPC (Google Remote Procedure Call)

gRPC usa Protocol Buffers (Protobuf) per la serializzazione binaria e HTTP/2 come trasporto. I servizi sono definiti in file .proto, e il codice client/server viene generato automaticamente. E progettato per comunicazioni low-latency service-to-service.

// gRPC: definizione del servizio in .proto
syntax = "proto3";

service UserService {
  rpc GetUser (GetUserRequest) returns (User);
  rpc ListUsers (ListUsersRequest) returns (stream User);
  rpc CreateUser (CreateUserRequest) returns (User);
}

message User {
  int64 id = 1;
  string name = 2;
  string email = 3;
}

message GetUserRequest {
  int64 id = 1;
}

tRPC (TypeScript Remote Procedure Call)

tRPC e un framework per TypeScript che elimina la dicotomia client-server: le definizioni TypeScript del backend sono direttamente disponibili nel frontend senza generazione di codice. Non e un protocollo di rete separato — usa HTTP standard — ma il type safety end-to-end e garantito dal compilatore TypeScript.

// tRPC: il tipo del backend e direttamente nel frontend
// Backend
const appRouter = router({
  getUser: publicProcedure
    .input(z.object({ id: z.number() }))
    .query(async ({ input }) => {
      return db.user.findUnique({ where: { id: input.id } });
    }),
});

// Frontend: TypeScript conosce il tipo di ritorno senza codegen
const user = await trpc.getUser.query({ id: 123 });
//    ^-- Il tipo e UserFromPrisma | null (inferito automaticamente)

La Matrice Decisionale 2026

La scelta del protocollo dovrebbe basarsi su questi fattori:

Scenario                        | Raccomandazione  | Motivazione
--------------------------------|-----------------|----------------------------------
API pubblica per sviluppatori   | REST             | Universalmente comprensibile,
terzi                           |                 | documentabile con OpenAPI
API mobile con dati complessi   | GraphQL          | Riduce over-fetching su reti lente
Service-to-service interno      | gRPC             | Latenza minima, schema tipizzato
Monorepo TypeScript full-stack  | tRPC             | Type safety senza overhead
Dashboard/admin con JOIN        | GraphQL          | Query flessibili su dati relazionali
Microservizi performance-critical| gRPC            | Payload 60-80% piu piccolo di JSON
App React/Next.js TypeScript    | tRPC             | DX eccellente, zero codegen
API partner (B2B)               | REST + OpenAPI   | Standard industriale, SDK generabili
Streaming dati real-time        | gRPC streaming   | Bidirectional streaming nativo
Aggregazione dati da piu servizi| GraphQL Federation| Supergraph unificato

REST: Perche Rimane al 70%

REST domina perche e il denominatore comune universale. Qualsiasi client HTTP puo consumare una REST API: curl, Postman, qualsiasi linguaggio di programmazione. Questo e cruciale per API pubbliche dove non controlli i client.

I vantaggi concreti di REST nel 2026:

Caching nativo HTTP: GET /users/123 e cacheable a tutti i livelli (CDN, browser, reverse proxy) senza configurazione extra
Tooling maturo: Postman, Insomnia, Swagger UI, generatori SDK — tutto funziona con REST
Semplicita di debugging: una richiesta HTTP standard e leggibile in qualsiasi tool di networking
Stateless per design: ogni richiesta e auto-contenuta, ideale per scaling orizzontale
Standard industriale: qualsiasi team conosce REST, riduce la curva di apprendimento

I limiti reali di REST:

Over-fetching: GET /users ritorna tutti i campi anche se il client ne vuole solo 2
Under-fetching: per mostrare utente + ordini + prodotti, spesso servono 3 chiamate API separate
Nessun tipo formale: senza OpenAPI, il contratto API e solo documentazione testuale
Versioning complicato: /v1 vs /v2 porta a proliferazione di endpoint

GraphQL: Hype Ridimensionato, Nicchia Confermata

Il calo da 32% a 25% nell'adozione di GraphQL riflette una maturazione: dopo anni in cui veniva usato come risposta a tutto, la community ha capito che GraphQL eccelle in scenari specifici ma introduce complessita sproporzionata in scenari semplici.

GraphQL brilla davvero quando:

Il client deve aggregare dati da piu entita in una singola richiesta (tipico nei BFF, Backend for Frontend)
Diversi client (mobile, web, dashboard) hanno bisogni molto diversi dagli stessi dati
Il team ha piu frontend teams che richiedono flessibilita indipendente dal backend

GraphQL introduce complessita non banale:

Il problema N+1 (risolto con DataLoader ma richiede comprensione)
Caching piu complesso rispetto a REST (non puoi fare HTTP caching dei GET)
Over-fetching nascosto: un client che richiede troppi campi puo scaricare il database
Autorizzazione field-level piu complessa

gRPC: Il Dominatore dei Microservizi

gRPC non e per tutti, ma per comunicazioni service-to-service in architetture microservizi e diventato lo standard de facto nei sistemi ad alta performance. I numeri lo confermano:

// Benchmark comparativo REST JSON vs gRPC Protobuf (dati reali 2025)
// Scenario: trasferimento lista di 1000 utenti tra microservizi

REST (JSON):
  Payload size: ~180 KB
  Serialization time: ~8ms
  P50 latency: 45ms
  P99 latency: 120ms

gRPC (Protobuf):
  Payload size: ~38 KB  (-79% rispetto a JSON)
  Serialization time: ~1.2ms
  P50 latency: 12ms     (-73% rispetto a REST)
  P99 latency: 28ms     (-77% rispetto a REST)

// Fonte: benchmark interni, hardware equivalente,
// Node.js 22 vs Go gRPC server

L'overhead di setup di gRPC (file .proto, code generation, compilatore Protobuf) si giustifica quando la performance e la type safety del contratto sono critiche, tipicamente per servizi che si chiamano centinaia o migliaia di volte al secondo.

tRPC: La Rivoluzione TypeScript

tRPC ha trovato la sua nicchia e la sta dominando: applicazioni TypeScript full-stack in monorepo dove frontend e backend condividono il codebase. La crescita al 15% nei ruoli TypeScript non e casuale: e la risposta a uno dei problemi piu frustranti dello sviluppo web moderno.

// Il problema che tRPC risolve:
// Senza tRPC: il tipo dell'API e "perduto" tra backend e frontend

// Backend (Node.js/Express)
app.get('/api/user/:id', async (req, res) => {
  const user = await db.findUser(req.params.id);
  res.json(user); // Il tipo di user e perso nella risposta
});

// Frontend: deve fare supposizioni sul tipo
const response = await fetch('/api/user/123');
const user: User = await response.json(); // Cast rischioso!
// Se il backend cambia, il frontend non lo sa fino a runtime

// Con tRPC: il tipo fluisce dal backend al frontend automaticamente
// Backend
const userRouter = router({
  getById: publicProcedure
    .input(z.object({ id: z.string() }))
    .query(async ({ input }) => {
      return db.findUser(input.id);
      // Il tipo di ritorno e inferito automaticamente
    }),
});

// Frontend: TypeScript conosce il tipo esatto
const { data: user } = trpc.user.getById.useQuery({ id: '123' });
// user ha il tipo esatto di db.findUser(...)
// Se cambi il backend, TypeScript ti avvisa immediatamente nel frontend

Limitazione Importante di tRPC

tRPC funziona SOLO con TypeScript su entrambi i lati. Non puoi usarlo per API pubbliche (dove i client sono in linguaggi diversi) o per comunicazioni tra microservizi in linguaggi eterogenei. E pensato per monorepo TypeScript dove hai controllo completo sia del frontend che del backend.

Architettura Ibrida: Usare Piu Protocolli Insieme

Nel mondo reale, i sistemi complessi spesso combinano piu protocolli, ognuno dove eccelle:

// Architettura ibrida tipica nel 2026
// per un'applicazione SaaS enterprise

Internet
    |
    v
[API Gateway / Load Balancer]
    |
    |-- REST (JSON/HTTPS) -----> [Public API] (partner, third-party)
    |
    |-- tRPC (HTTP/TypeScript) -> [Next.js BFF] (frontend dashboard)
    |
    +-- [Auth Service]
         |
         |-- gRPC -------> [User Service] (microservizio)
         |-- gRPC -------> [Billing Service] (microservizio)
         |-- gRPC -------> [Notification Service] (microservizio)
         |
         +-- [Message Queue] (Kafka/RabbitMQ)
              |-- Event streaming per analytics e audit

Questo pattern e estremamente comune nelle aziende tech del 2026:

REST verso l'esterno per interoperabilita con client eterogenei
tRPC per il dashboard interno TypeScript, massimizzando DX e type safety
gRPC tra microservizi per performance e contratti formali

Checklist per la Scelta del Protocollo

Prima di decidere, rispondi a queste domande:

CHECKLIST API PROTOCOL SELECTION
=================================

1. CHI CONSUMA L'API?
   [ ] Terze parti / sviluppatori esterni  -> REST
   [ ] Solo il tuo frontend TypeScript     -> tRPC
   [ ] Altri microservizi interni          -> gRPC
   [ ] Multipli client con bisogni diversi -> GraphQL

2. REQUISITI DI PERFORMANCE?
   [ ] Latenza sub-10ms critica            -> gRPC
   [ ] Performance "buona" e sufficiente  -> REST o tRPC
   [ ] Mobile su reti lente               -> GraphQL (meno over-fetch)

3. LINGUAGGI DEL TEAM?
   [ ] Solo TypeScript full-stack          -> tRPC (DX ottimale)
   [ ] Java/Go/Python backend + TS front  -> REST o gRPC
   [ ] Mixed languages                    -> REST (universale)

4. COMPLESSITA DEI DATI?
   [ ] Dati semplici, endpoint CRUD        -> REST
   [ ] Dati correlati, query flessibili    -> GraphQL
   [ ] Contratto binario performante       -> gRPC

5. CACHING IMPORTANTE?
   [ ] Si, CDN e browser cache critici     -> REST (GET caching nativo)
   [ ] No, tutto e user-specific           -> Qualsiasi

Conclusioni e Prossimi Passi

Non esiste un "vincitore" universale tra REST, GraphQL, gRPC e tRPC. La scelta corretta dipende da chi consuma l'API, dai requisiti di performance, dal linguaggio del team e dalla complessita dei dati. La buona notizia: non devi scegliere uno solo — le architetture ibride che combinano piu protocolli sono la norma nei sistemi enterprise moderni.

I prossimi articoli di questa serie approfondiscono ciascun protocollo in dettaglio. Il prossimo e REST nel 2026: Best Practice, Versioning e Richardson Maturity Model — un deep dive su come implementare REST correttamente, perche la maggior parte delle "REST API" non sono veramente RESTful, e come OpenAPI 3.1 risolve il problema del contratto formale.

Serie: API Design — REST, GraphQL, gRPC e tRPC a Confronto

Articolo 1 (questo): Il Panorama delle API nel 2026 — Matrice Decisionale
Articolo 2: REST nel 2026 — Best Practice, Versioning e Richardson Maturity Model
Articolo 3: GraphQL — Query Language, Resolver e il Problema N+1
Articolo 4: GraphQL Federation — Supergraph, Subgraph e Apollo Router
Articolo 5: gRPC — Protobuf, Performance e Comunicazione Service-to-Service
Articolo 6: tRPC — Type Safety End-to-End senza Code Generation
Articolo 7: Webhooks — Pattern, Sicurezza e Retry Logic
Articolo 8: API Versioning — URI, Header e Deprecation Policy
Articolo 9: Rate Limiting e Throttling — Algoritmi e Implementazioni
Articolo 10: Architettura API Ibrida — REST + tRPC + gRPC nel 2026