Cześć! Jestem

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.

Skontaktuj się

O Mnie

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.

Moje Umiejętności

Analisi Dati & Modelli Previsionali

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

Automatyzacja Procesów

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

Systemy Na Zamówienie

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

Moja Misja

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

Demokratyzacja Technologii

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.

Łączenie IT i Biznesu

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

Tworzenie Rozwiązań na Miarę

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.

Przekształć Swój Biznes z Technologią

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.

Porozmawiajmy →

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.

Skontaktuj się

Masz projekt? Porozmawiajmy! Wypełnij formularz, a odpowiem wkrótce.

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

Krajobraz API w 2026 r.: REST, GraphQL, gRPC, tRPC — kiedy czego używać

Rozpoczynasz nowy projekt i musisz wybrać protokół API. ODPOCZYNEK? WykresQL? gRPC? tRPC? Właściwą odpowiedzią w 2026 roku nie jest „najnowocześniejszy” ani „ten, którego wszyscy używają”, ale zależy od konkretnych czynników: rodzaju klienta (publiczny czy wewnętrzny), wymagań dotyczących opóźnień, umiejętności zespołu i kontekst aplikacji.

Przegląd ten buduje praktyczna matryca decyzyjna w oparciu o dane realne: REST pojawia się w 70% ogłoszeń o pracę zaplecza, GraphQL i spada do 25% (z 32% w 2023 r.) po latach szumu odsetek tRPC rośnie do 15% w rolach TypeScript, a dominuje gRPC Komunikacja między usługami w mikroserwisach. Zrozum, dlaczego te liczby istnieją pomaga dokonać właściwego wyboru.

Czego się nauczysz

Podstawowe cechy REST, GraphQL, gRPC i tRPC
Matryca decyzyjna: który protokół dla jakiego scenariusza
Dane dotyczące przyjęcia i trendy rynkowe w 2026 r
Prawdziwe kompromisy w każdym podejściu
Jak połączyć wiele protokołów w tej samej architekturze
Lista kontrolna wyboru protokołu API

Cztery protokoły: szybki przegląd

Zanim zagłębimy się w macierz decyzyjną, zdefiniujmy dokładnie, co robi każdy protokół:

REST (reprezentacyjny transfer stanu)

REST to architektura, a nie protokół. Opiera się na standardowym protokole HTTP z adresami URL jako zasobami, Czasowniki HTTP (GET, POST, PUT, DELETE) jako akcje i JSON jako dominujący format ładunku. REST nie ma formalnego schematu (OpenAPI jest de facto standardem, a nie częścią REST oryginał), nie ma języka zapytań, a każdy punkt końcowy udostępnia określony zasób.

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

WykresQL

GraphQL to język zapytań dla interfejsów API, w którym klient dokładnie określa, jakie dane chce. Istnieje jeden punkt końcowy (zwykle POST /graphql), a klient wysyła plik zapytanie opisujące strukturę żądanych danych. Schemat jest formalną i typową umową.

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

gRPC (Zdalne wywołanie procedury Google)

gRPC używa buforów protokołu (Protobuf) do serializacji binarnej i protokołu HTTP/2 jako transportu. Usługi są zdefiniowane w plikach .protoi generowany jest kod klienta/serwera automatycznie. Zaprojektowany z myślą o komunikacji między usługami o niskim opóźnieniu.

// 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 (zdalne wywołanie procedury TypeScript)

tRPC to framework dla TypeScriptu, który eliminuje dychotomię klient-serwer: definicje Skrypty TypeScript zaplecza są dostępne bezpośrednio w interfejsie bez generowania kodu. Nie jest to oddzielny protokół sieciowy — wykorzystuje standardowy protokół HTTP — ale bezpieczeństwo typu end-to-end i gwarantowane przez kompilator 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)

Matryca decyzyjna na rok 2026

Wybór protokołu powinien opierać się na następujących czynnikach:

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

ODPOCZYNEK: Dlaczego pozostaje na poziomie 70%

REST dominuje, ponieważ jest uniwersalnym wspólnym mianownikiem. Każdy klient HTTP może korzystać API REST: curl, Postman, dowolny język programowania. Jest to kluczowe dla Publiczne interfejsy API, w których nie kontrolujesz klientów.

Konkretne korzyści REST w 2026 roku:

Natywne buforowanie HTTP: GET /users/123 i możliwość buforowania na wszystkich poziomach (CDN, przeglądarka, odwrotne proxy) bez dodatkowej konfiguracji
Dojrzałe oprzyrządowanie: Postman, Insomnia, Swagger UI, generatory SDK – wszystko działa z REST
Łatwość debugowania: standardowe żądanie HTTP i można je odczytać w dowolnym narzędziu sieciowym
Bezpaństwowiec z założenia: każde żądanie jest samodzielne, idealne do skalowania poziomego
Standard branżowy: każdy zespół zna REST, skraca to krzywą uczenia się

Prawdziwe ograniczenia REST:

Nadmierne pobieranie: GET /users zwraca wszystkie pola, nawet jeśli klient chce tylko 2
Niedostateczne pobieranie: aby pokazać użytkownika + zamówienia + produkty często wymagane są 3 oddzielne wywołania API
Brak typu formalnego: bez OpenAPI, umowa API i tylko dokumentacja tekstowa
Skomplikowane wersjonowanie: /v1 vs /v2 prowadzi do proliferacji punktów końcowych

GraphQL: skalowany szum, potwierdzona nisza

Spadek liczby zastosowań GraphQL z 32% do 25% odzwierciedla dojrzewanie: po latach został użyty jako odpowiedź na wszystko, społeczność zdała sobie sprawę, że GraphQL przoduje w scenariuszach specyficzny, ale wprowadza nieproporcjonalną złożoność w prostych scenariuszach.

GraphQL naprawdę błyszczy, gdy:

Klient musi agregować dane z wielu podmiotów w jednym żądaniu (typowe w BFF, Backend for Frontend)
Różni klienci (mobilni, internetowi, dashboard) mają bardzo różne potrzeby w zakresie tych samych danych
Zespół składa się z wielu zespołów frontendowych, które wymagają elastyczności niezależnej od backendu

GraphQL wprowadza nietrywialną złożoność:

Problem N+1 (rozwiązany za pomocą DataLoader, ale wymaga zrozumienia)
Bardziej złożone buforowanie niż REST (nie można buforować HTTP GET)
Ukryte nadmierne pobieranie: klient żądający zbyt wielu pól może zrzucić bazę danych
Bardziej złożona autoryzacja na poziomie pola

gRPC: Władca mikrousług

gRPC nie jest przeznaczony dla wszystkich, ale do komunikacji między usługami w architekturach mikrousług i stał się de facto standardem w systemach o wysokiej wydajności. Potwierdzają to liczby:

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

Narzut związany z konfiguracją gRPC (plik .proto, generowanie kodu, kompilator Protobuf) jest uzasadniony gdy wykonanie i bezpieczeństwo typu zamówienia są krytyczne, zazwyczaj w przypadku usług które są wywoływane setki lub tysiące razy na sekundę.

tRPC: rewolucja TypeScriptu

tRPC znalazło swoją niszę i ją dominuje: aplikacje TypeScript z pełnym stosem w monorepo gdzie frontend i backend dzielą bazę kodu. 15% wzrost liczby ról TypeScript nie jest losowy: to odpowiedź na jeden z najbardziej frustrujących problemów współczesnego tworzenia stron internetowych.

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

Ważne ograniczenie tRPC

tRPC działa TYLKO z TypeScriptem po obu stronach. Nie można go używać w publicznych interfejsach API (gdzie klienci są w różnych językach) lub do komunikacji pomiędzy mikrousługami w języki heterogeniczne. Jest przeznaczony dla monorepo TypeScript, gdzie masz pełną kontrolę zarówno frontend, jak i backend.

Architektura hybrydowa: jednoczesne korzystanie z wielu protokołów

W prawdziwym świecie złożone systemy często łączą wiele protokołów, a każdy z nich sprawdza się najlepiej:

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

Ten wzorzec jest niezwykle powszechny w firmach technologicznych w 2026 r.:

ODPOCZYWAJ na zewnątrz dla interoperacyjności z heterogenicznymi klientami
tRPC dla wewnętrznego pulpitu nawigacyjnego TypeScript, maksymalizujący DX i bezpieczeństwo typów
gRPC między mikrousługami do umów wykonawczych i formalnych

Lista kontrolna wyboru protokołu

Zanim podejmiesz decyzję, odpowiedz sobie na następujące pytania:

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

Wnioski i dalsze kroki

Nie ma uniwersalnego „zwycięzcy” pomiędzy REST, GraphQL, gRPC i tRPC. Właściwy wybór zależy od tego, kto korzysta z interfejsu API, wymagań dotyczących wydajności, języka zespołu i złożoność danych. Dobra wiadomość: nie musisz wybierać tylko jednej — architektury hybrydowej łączące wiele protokołów są normą w nowoczesnych systemach korporacyjnych.

Kolejne artykuły z tej serii szczegółowo omawiają każdy protokół. Następny tj REST w 2026 r.: najlepsze praktyki, wersjonowanie i model dojrzałości Richardsona — a głębokie nurkowanie na temat prawidłowego wdrażania REST, dlaczego większość „REST API” nie są tak naprawdę RESTful i podobnie jak OpenAPI 3.1 rozwiązują formalny problem kontraktowy.

Seria: Projektowanie API — porównanie REST, GraphQL, gRPC i tRPC

Artykuł 1 (ten): Krajobraz API w 2026 r. – macierz decyzyjna
Artykuł 2: REST w 2026 r. – najlepsze praktyki, wersjonowanie i model dojrzałości Richardsona
Artykuł 3: GraphQL — język zapytań, narzędzie do rozwiązywania problemów i problem N+1
Artykuł 4: Federacja GraphQL — Supergraph, Subgraph i Router Apollo
Artykuł 5: gRPC — Protobuf, wydajność i komunikacja między usługami
Artykuł 6: tRPC — kompleksowe bezpieczeństwo typu bez generowania kodu
Artykuł 7: Elementy webhook — wzorce, zabezpieczenia i logika ponownych prób
Artykuł 8: Wersjonowanie API – URI, nagłówki i zasady wycofywania
Artykuł 9: Ograniczanie i dławienie szybkości — algorytmy i implementacje
Artykuł 10: Architektura hybrydowego API – REST + tRPC + gRPC w 2026 r