Ahoj! Jsem

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.

Kontaktujte Mě

O Mně

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.

Mé Dovednosti

Analisi Dati & Modelli Previsionali

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

Automatizace Procesů

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

Systémy na Míru

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

Mé Poslání

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

🚀

Demokratizovat Technologie

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.

💡

Propojení IT a Ekonomiky

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

🎯

Tvorba Řešení na Míru

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.

Transformujte Své Podnikání Technologiemi

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.

Kontaktujte Mě

Máte projekt na mysli? Pojďme si promluvit! Vyplňte formulář a brzy se ozvu.

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

Krajina API v roce 2026: REST, GraphQL, gRPC, tRPC – kdy co použít

Začínáte nový projekt a musíte zvolit protokol API. ODPOČINEK? GraphQL? gRPC? tRPC? Správná odpověď v roce 2026 není „ten nejmodernější“ nebo „ten, který všichni používají“, ale závisí na konkrétních faktorech: typ klienta (veřejný vs. interní), požadavky na latenci, dovednosti týmu a kontext aplikace.

Tento přehled vytváří a praktická rozhodovací matice na základě dat skutečný: REST se objevuje v 70 % backendových pracovních nabídek, GraphQL a až 25 % (z 32 % v roce 2023) po letech humbuku roste tRPC na 15 % v rolích TypeScript a dominuje gRPC komunikace mezi službami v mikroslužbách. Pochopte, proč tato čísla existují vám pomůže udělat správnou volbu.

Co se naučíte

Základní vlastnosti REST, GraphQL, gRPC a tRPC
Rozhodovací matice: jaký protokol pro který scénář
Údaje o přijetí v roce 2026 a trendy na trhu
Skutečné kompromisy každého přístupu
Jak kombinovat více protokolů ve stejné architektuře
Kontrolní seznam pro výběr protokolu API

Čtyři protokoly: Rychlý přehled

Než se ponoříme do rozhodovací matice, pojďme přesně definovat, co každý protokol dělá:

REST (převod reprezentativního státu)

REST je architektura, nikoli protokol. Je založen na standardním HTTP s adresami URL jako zdroji, Slovesa HTTP (GET, POST, PUT, DELETE) jako akce a JSON jako převládající formát užitečného zatížení. REST nemá formální schéma (OpenAPI je de facto standard, není součástí REST originál), nemá žádný dotazovací jazyk a každý koncový bod odhaluje konkrétní zdroj.

// 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 je dotazovací jazyk pro API, kde klient přesně specifikuje jaká data chce. Existuje jeden koncový bod (obvykle POST /graphql) a klient odešle a dotaz, který popisuje strukturu požadovaných dat. Schéma je formální a typizovaná smlouva.

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

gRPC (vzdálené volání procedur Google)

gRPC používá protokolové vyrovnávací paměti (Protobuf) pro binární serializaci a HTTP/2 jako transport. Služby jsou definovány v souborech .protoa vygeneruje se kód klient/server automaticky. A navrženo pro komunikaci mezi službami s nízkou latencí.

// 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 (Vzdálené volání procedur TypeScript)

tRPC je framework pro TypeScript, který eliminuje dichotomii klient-server: definice Backend TypeScripts jsou přímo dostupné ve frontendu bez generování kódu. Nejedná se o samostatný síťový protokol – používá standardní HTTP – ale o zabezpečení typu end-to-end a garantováno kompilátorem 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)

Rozhodovací matice 2026

Volba protokolu by měla být založena na těchto faktorech:

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: Proč zůstává na 70 %

REST dominuje, protože je univerzálním společným jmenovatelem. Spotřebovat může jakýkoli HTTP klient REST API: curl, Postman, jakýkoli programovací jazyk. To je zásadní pro Veřejná rozhraní API, kde neřídíte klienty.

Konkrétní výhody REST v roce 2026:

HTTP nativní mezipaměť: GET /users/123 a cacheable na všech úrovních (CDN, prohlížeč, reverzní proxy) bez zvláštní konfigurace
Vyspělé nástroje: Postman, Insomnia, Swagger UI, generátory SDK — vše funguje s REST
Snadné ladění: standardní požadavek HTTP a čitelný v jakémkoli síťovém nástroji
Design bez státní příslušnosti: každý požadavek je samostatný, ideální pro horizontální škálování
Průmyslový standard: každý tým zná REST, snižuje to křivku učení

Skutečné limity REST:

Nadměrné načítání: GET /users vrátí všechna pole, i když klient chce pouze 2
Nedostatečné načítání: zobrazení uživatele + objednávky + produkty často vyžaduje 3 samostatná volání API
Žádný formální typ: bez OpenAPI, smlouvy API a pouze textové dokumentace
Složité verzování: /v1 vs /v2 vede ke koncové proliferaci

GraphQL: Hype Scaled, Niche potvrzeno

Pokles z 32 % na 25 % v přijetí GraphQL odráží zrání: po letech byl použit jako odpověď na všechno, komunita si uvědomila, že GraphQL vyniká ve scénářích specifické, ale v jednoduchých scénářích zavádí nepřiměřenou složitost.

GraphQL opravdu září, když:

Klient musí agregovat data z více entit v jednom požadavku (typické v BFF, Backend for Frontend)
Různí klienti (mobil, web, dashboard) mají velmi odlišné potřeby od stejných dat
Tým má několik frontendových týmů, které vyžadují flexibilitu nezávislou na backendu

GraphQL zavádí netriviální složitost:

Problém N+1 (vyřešeno pomocí DataLoader, ale vyžaduje pochopení)
Složitější ukládání do mezipaměti než REST (nemůžete provádět ukládání GET do mezipaměti HTTP)
Skryté nadměrné načítání: Klient požadující příliš mnoho polí může vypsat databázi
Složitější oprávnění na úrovni pole

gRPC: Vládce mikroslužeb

gRPC není pro každého, ale pro komunikaci mezi službami v architektuře mikroslužeb a stal se de facto standardem ve vysoce výkonných systémech. Čísla to potvrzují:

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

Režie nastavení gRPC (soubor .proto, generování kódu, kompilátor Protobuf) je oprávněná když je kritická výkonnost a typová bezpečnost smlouvy, obvykle pro služby které jsou volány stovky nebo tisícekrát za sekundu.

tRPC: Revoluce v TypeScriptu

tRPC našlo své místo a dominuje mu: full-stack aplikace TypeScript v monorepo kde frontend a backend sdílejí kódovou základnu. 15% nárůst rolí TypeScript není náhodně: je to odpověď na jeden z nejvíce frustrujících problémů v moderním vývoji webu.

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

Důležité omezení tRPC

tRPC funguje POUZE s TypeScript na obou stranách. Nemůžete jej použít pro veřejná API (kde jsou klienti v různých jazycích) nebo pro komunikaci mezi mikroslužbami v heterogenní jazyky. Je určen pro monorepo TypeScript, kde máte úplnou kontrolu jak frontend, tak backend.

Hybridní architektura: Použití více protokolů společně

V reálném světě složité systémy často kombinují více protokolů, z nichž každý vyniká:

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

Tento vzor je v technologických společnostech v roce 2026 extrémně běžný:

ODPOČINEK směrem ven pro interoperabilitu s heterogenními klienty
tRPC pro vnitřní palubní desku TypeScript, maximalizující DX a bezpečnost typu
gRPC mezi mikroslužbami pro plnění a formální smlouvy

Kontrolní seznam pro výběr protokolu

Než se rozhodnete, odpovězte si na tyto otázky:

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

Závěry a další kroky

Mezi REST, GraphQL, gRPC a tRPC neexistuje žádný univerzální „vítěz“. Správná volba závisí na tom, kdo používá rozhraní API, požadavcích na výkon, jazyku týmu a složitost dat. Dobrá zpráva: Nemusíte si vybrat jen jednu — hybridní architektury které kombinují více protokolů jsou normou v moderních podnikových systémech.

Další články této série se podrobně ponoří do každého protokolu. Další e REST in 2026: Best Practice, Versioning a Richardson Maturity Model — a ponořit se do toho, jak správně implementovat REST, proč většina "REST API" nejsou skutečně RESTful a stejně jako OpenAPI 3.1 řeší problém formální smlouvy.

Řada: Design API – porovnání REST, GraphQL, gRPC a tRPC

Článek 1 (tento): Krajina API v roce 2026 — rozhodovací matice
Článek 2: REST v roce 2026 – Best Practice, Versioning a Richardson Maturity Model
Článek 3: GraphQL – Dotazovací jazyk, Resolver a problém N+1
Článek 4: GraphQL Federation — Supergraph, Subgraph a Apollo Router
Článek 5: gRPC – Protobuf, Performance a Service-to-Service Communication
Článek 6: tRPC – typová bezpečnost end-to-end bez generování kódu
Článek 7: Webhooky – vzory, zabezpečení a logika opakování
Článek 8: Verze rozhraní API – Zásady URI, záhlaví a ukončení podpory
Článek 9: Omezení a omezování rychlosti – Algoritmy a implementace
Článek 10: Hybrid API Architecture – REST + tRPC + gRPC v roce 2026