Hallo! Ik ben

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.

Neem Contact Op

Over Mij

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.

Mijn Vaardigheden

Analisi Dati & Modelli Previsionali

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

Procesautomatisering

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

Maatwerksystemen

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"
  ]
};

Mijn Missie

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

Technologie Democratiseren

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.

IT en Business Verenigen

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à.

Maatwerkoplossingen Creëren

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.

Transformeer Uw Bedrijf met Technologie

Che tu gestisca un negozio, uno studio professionale o un'azienda, posso aiutarti a sfruttare le potenzialità dell'informatica per lavorare meglio, più velocemente e in modo più intelligente.

Laten We Praten →

Unisciti alla Community

Entra nella community di sviluppatori dove discutiamo di software, AI, architettura e DevOps. Condividi idee, fai domande e cresci insieme a noi.

Canale

FC Dev Blog

Ricevi notifiche su nuovi articoli, serie complete, tips settimanali e tool in evidenza. Contenuti bilingui IT/EN direttamente nel tuo Telegram.

Nuovi articoli appena pubblicati
Tips e code snippets settimanali
Sondaggi sugli argomenti futuri

Iscriviti al Canale

Gruppo

FC Dev Community

Una community bilingue IT/EN per sviluppatori. Discussioni, Q&A, aiuto reciproco e networking con altri professionisti del settore.

Discussioni su articoli e tecnologie
Help coding e code review
Opportunità di lavoro e collaborazione

Unisciti al Gruppo

Topic di Discussione

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.

Neem Contact Op

Heeft u een project in gedachten? Laten we praten! Vul het formulier in en ik reageer snel.

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

Het API-landschap in 2026: REST, GraphQL, gRPC, tRPC – Wanneer moet u wat gebruiken

U start een nieuw project en moet het API-protocol kiezen. REST? GrafiekQL? gRPC? tRPC? Het juiste antwoord in 2026 is niet ‘het modernste’ of ‘hetgene dat iedereen gebruikt’, maar hangt af van concrete factoren: het type klant (openbaar versus intern), latentievereisten, de vaardigheden van het team en de context van de toepassing.

Dit overzicht bouwt een praktische beslissingsmatrix op basis van gegevens echt: REST verschijnt in 70% van de backend-vacatures, GraphQL en tot 25% (van 32% in 2023) na jaren van hype groeit tRPC naar 15% in TypeScript-rollen, en domineert gRPC service-to-service-communicatie in microservices. Begrijp waarom deze cijfers bestaan helpt u bij het maken van de juiste keuze.

Wat je gaat leren

Fundamentele kenmerken van REST, GraphQL, gRPC en tRPC
Beslissingsmatrix: welk protocol voor welk scenario
2026 adoptiegegevens en markttrends
Echte afwegingen tussen elke aanpak
Hoe meerdere protocollen in dezelfde architectuur te combineren
Checklist voor het kiezen van het API-protocol

De vier protocollen: snel overzicht

Laten we, voordat we ons verdiepen in de beslissingsmatrix, precies definiëren wat elk protocol doet:

REST (representatieve staatsoverdracht)

REST is een architectuur, geen protocol. Het is gebaseerd op standaard HTTP met URL's als bronnen, HTTP-werkwoorden (GET, POST, PUT, DELETE) als acties en JSON als het overheersende payload-formaat. REST heeft geen formeel schema (OpenAPI is een de facto standaard, geen onderdeel van REST origineel), heeft geen querytaal en elk eindpunt stelt een specifieke bron bloot.

// 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

GrafiekQL

GraphQL is een querytaal voor API's waarbij de klant precies specificeert welke gegevens wil. Er is één eindpunt (meestal POST /graphql), en de klant stuurt een query die de structuur van de opgevraagde gegevens beschrijft. Het schema is het formele en getypeerde contract.

// 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 maakt gebruik van Protocol Buffers (Protobuf) voor binaire serialisatie en HTTP/2 als transport. Diensten worden gedefinieerd in bestanden .protoen de client/servercode wordt gegenereerd automatisch. En ontworpen voor service-to-service-communicatie met lage latentie.

// 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 is een raamwerk voor TypeScript dat de tweedeling tussen client en server elimineert: de definities Backend TypeScripts zijn direct beschikbaar in de frontend zonder codegeneratie. Het is geen afzonderlijk netwerkprotocol – het gebruikt standaard HTTP – maar end-to-end-veiligheid en gegarandeerd door de TypeScript-compiler.

// 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)

De beslissingsmatrix van 2026

De keuze van het protocol moet gebaseerd zijn op deze factoren:

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: Waarom het op 70% blijft

REST domineert omdat het de universele gemene deler is. Elke HTTP-client kan verbruiken een REST API: curl, Postman, elke programmeertaal. Dit is cruciaal voor Openbare API's waarbij u geen controle heeft over de clients.

De concrete voordelen van REST in 2026:

HTTP-native caching: GET /user/123 en cachebaar op alle niveaus (CDN, browser, reverse proxy) zonder extra configuratie
Volwassen gereedschap: Postman, Insomnia, Swagger UI, SDK-generatoren: alles werkt met REST
Gemak van foutopsporing: een standaard HTTP-verzoek en leesbaar in elke netwerktool
Staatloos door ontwerp: elk verzoek staat op zichzelf, ideaal voor horizontale schaalvergroting
Industriestandaard: elk team kent REST, het verkort de leercurve

De echte grenzen van REST:

Overmatig ophalen: GET /users retourneert alle velden, zelfs als de klant er maar 2 wil
Onderophalen: om gebruiker + bestellingen + producten te tonen zijn vaak 3 afzonderlijke API-aanroepen nodig
Geen formeel type: zonder OpenAPI, het API-contract en alleen tekstuele documentatie
Gecompliceerd versiebeheer: /v1 vs /v2 leidt tot eindpuntproliferatie

GraphQL: hype geschaald, niche bevestigd

De daling van 32% naar 25% in de acceptatie van GraphQL weerspiegelt een rijping: na jaren van werd gebruikt als antwoord op alles, realiseerde de gemeenschap zich dat GraphQL uitblinkt in scenario's specifiek, maar introduceert onevenredige complexiteit in eenvoudige scenario's.

GraphQL schittert echt wanneer:

De klant moet gegevens van meerdere entiteiten in één verzoek samenvoegen (typisch in BFF, Backend voor Frontend)
Verschillende klanten (mobiel, web, dashboard) hebben zeer verschillende behoeften op basis van dezelfde data
Het team heeft meerdere frontendteams die backend-onafhankelijke flexibiliteit vereisen

GraphQL introduceert niet-triviale complexiteit:

Het N+1-probleem (opgelost met DataLoader maar vereist begrip)
Complexere caching dan REST (u kunt geen HTTP-caching van GET's uitvoeren)
Verborgen overophalen: een client die te veel velden opvraagt, kan de database dumpen
Complexere autorisatie op veldniveau

gRPC: de heerser van microservices

gRPC is niet voor iedereen bedoeld, maar voor service-to-service-communicatie in microservice-architecturen en is de de facto standaard geworden voor hoogwaardige systemen. De cijfers bevestigen het:

// 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

gRPC-setup-overhead (.proto-bestand, codegeneratie, Protobuf-compiler) is gerechtvaardigd wanneer de prestaties en de typeveiligheid van het contract van cruciaal belang zijn, doorgaans voor diensten die honderden of duizenden keren per seconde worden gebeld.

tRPC: de TypeScript-revolutie

tRPC heeft zijn niche gevonden en domineert deze: full-stack TypeScript-applicaties in monorepo waarbij frontend en backend de codebase delen. De groei van 15% in TypeScript-rollen is dat niet willekeurig: het is het antwoord op een van de meest frustrerende problemen bij moderne webontwikkeling.

// 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

Belangrijke beperking van tRPC

tRPC werkt ALLEEN met TypeScript aan beide kanten. U kunt het niet gebruiken voor openbare API's (waar clients in verschillende talen zijn) of voor communicatie tussen microservices in heterogene talen. Het is ontworpen voor TypeScript-monorepos waar u volledige controle heeft zowel de frontend als de backend.

Hybride architectuur: meerdere protocollen samen gebruiken

In de echte wereld combineren complexe systemen vaak meerdere protocollen, elk waarin ze uitblinken:

// 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

Dit patroon is anno 2026 heel gebruikelijk bij technologiebedrijven:

RUST naar buiten voor interoperabiliteit met heterogene klanten
tRPC voor het interne dashboard TypeScript, maximaliseert DX en typeveiligheid
gRPC tussen microservices voor prestatie en formele contracten

Controlelijst voor protocolselectie

Beantwoord deze vragen voordat u beslist:

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

Conclusies en volgende stappen

Er is geen universele ‘winnaar’ tussen REST, GraphQL, gRPC en tRPC. De juiste keuze hangt af van wie de API gebruikt, prestatievereisten, teamtaal en complexiteit van de gegevens. Het goede nieuws: u hoeft niet slechts één architectuur te kiezen: hybride architecturen die meerdere protocollen combineren, zijn de norm in moderne bedrijfssystemen.

De volgende artikelen in deze serie gaan gedetailleerd in op elk protocol. Volgende e REST in 2026: best practices, versiebeheer en het Richardson Maturity Model – een diepgaande informatie over hoe u REST correct implementeert, waarom de meeste "REST API's" ze zijn niet echt RESTful, en net als OpenAPI 3.1 lost het het formele contractprobleem op.

Serie: API-ontwerp — REST, GraphQL, gRPC en tRPC vergeleken

Artikel 1 (dit): Het API-landschap in 2026: beslissingsmatrix
Artikel 2: REST in 2026 – Best Practice, versiebeheer en het Richardson Maturity Model
Artikel 3: GraphQL — Querytaal, Resolver en het N+1-probleem
Artikel 4: GraphQL Federatie — Supergraph, Subgraph en Apollo Router
Artikel 5: gRPC — Protobuf, prestaties en service-to-service-communicatie
Artikel 6: tRPC — Typeveiligheid end-to-end zonder codegeneratie
Artikel 7: Webhooks — Patronen, beveiliging en logica voor opnieuw proberen
Artikel 8: API-versiebeheer — URI, koptekst en beëindigingsbeleid
Artikel 9: Snelheidsbeperking en -beperking — Algoritmen en implementaties
Artikel 10: Hybride API-architectuur — REST + tRPC + gRPC in 2026