Bună! Sunt

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.

Contactează-mă

Despre Mine

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.

Competențele Mele

Analisi Dati & Modelli Previsionali

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

Automatizarea Proceselor

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

Sisteme Personalizate

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

Misiunea Mea

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

Democratizarea Tehnologiei

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.

Unirea IT și Economiei

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

Crearea de Soluții Personalizate

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.

Transformă-ți Afacerea cu Tehnologia

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.

Hai să Vorbim →

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.

Contactează-mă

Ai un proiect în minte? Hai să vorbim! Completează formularul și îți voi răspunde curând.

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

Peisajul API în 2026: REST, GraphQL, gRPC, tRPC — Când să folosiți Ce

Începeți un nou proiect și trebuie să alegeți protocolul API. ODIHNĂ? GraphQL? gRPC? tRPC? Răspunsul corect în 2026 nu este „cel mai modern” sau „cel pe care îl folosește toată lumea”, ci depinde de factori concreți: tipul de client (public vs intern), cerințele de latență, abilitățile echipei și contextul aplicației.

Această prezentare generală construiește a matrice de decizie practică pe baza datelor real: REST apare în 70% din postările de locuri de muncă din backend, GraphQL și până la 25% (de la 32% în 2023) după ani de hype, tRPC crește la 15% în rolurile TypeScript, iar gRPC domină comunicații de la serviciu la serviciu în microservicii. Înțelegeți de ce există aceste numere te ajută să faci alegerea corectă.

Ce vei învăța

Caracteristici fundamentale ale REST, GraphQL, gRPC și tRPC
Matricea de decizie: ce protocol pentru ce scenariu
Datele privind adoptarea din 2026 și tendințele pieței
Compensații reale ale fiecărei abordări
Cum să combinați mai multe protocoale în aceeași arhitectură
Lista de verificare pentru alegerea protocolului API

Cele patru protocoale: prezentare rapidă

Înainte de a pătrunde în matricea de decizie, să definim exact ce face fiecare protocol:

REST (Transfer de stat reprezentativ)

REST este o arhitectură, nu un protocol. Se bazează pe HTTP standard cu adrese URL ca resurse, Verbele HTTP (GET, POST, PUT, DELETE) ca acțiuni și JSON ca format de încărcare utilă predominant. REST nu are o schemă formală (OpenAPI este un standard de facto, nu face parte din REST original), nu are limbaj de interogare și fiecare punct final expune o anumită resursă.

// 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 este un limbaj de interogare pentru API-uri în care clientul specifică exact ce date vrea. Există un singur punct final (de obicei POST /graphql), iar clientul trimite un interogare care descrie structura datelor solicitate. Schema este contractul formal și tipificat.

// 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 utilizează Protocol Buffers (Protobuf) pentru serializarea binară și HTTP/2 ca transport. Serviciile sunt definite în fișiere .proto, iar codul client/server este generat automat. Și conceput pentru comunicații de la serviciu la serviciu cu latență scăzută.

// 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 (Apel de procedură la distanță TypeScript)

tRPC este un cadru pentru TypeScript care elimină dihotomia client-server: definițiile Backend TypeScript-urile sunt disponibile direct în frontend fără generare de cod. Nu este un protocol de rețea separat - folosește HTTP standard - ci siguranță de tip end-to-end și garantat de compilatorul 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)

Matricea deciziei 2026

Alegerea protocolului ar trebui să se bazeze pe acești factori:

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: De ce rămâne la 70%

REST domină pentru că este numitorul comun universal. Orice client HTTP poate consuma o API REST: curl, Postman, orice limbaj de programare. Acest lucru este crucial pentru API-uri publice în care nu controlați clienții.

Beneficiile concrete ale REST în 2026:

Cache nativă HTTP: GET /users/123 și poate fi stocat în cache la toate nivelurile (CDN, browser, proxy invers) fără configurare suplimentară
Scule mature: Postman, Insomnia, Swagger UI, generatoare SDK — totul funcționează cu REST
Ușurință de depanare: o cerere HTTP standard și care poate fi citită în orice instrument de rețea
Apatrid prin proiectare: fiecare cerere este autonomă, ideală pentru scalarea orizontală
Standard industrial: orice echipă știe REST, reduce curba de învățare

Adevăratele limite ale REST:

Preluare excesivă: GET /users returnează toate câmpurile chiar dacă clientul dorește doar 2
Preluare insuficientă: pentru a afișa utilizator + comenzi + produse necesită adesea 3 apeluri API separate
Fără tip formal: fără OpenAPI, contractul API și doar documentație textuală
Versiuni complicate: /v1 vs /v2 duce la proliferarea punctelor finale

GraphQL: Hype Scaled, Nișă confirmată

Scăderea de la 32% la 25% în adoptarea GraphQL reflectă o maturizare: după ani de a fost folosit ca răspuns la toate, comunitatea și-a dat seama că GraphQL excelează în scenarii specific dar introduce o complexitate disproporționată în scenarii simple.

GraphQL strălucește cu adevărat atunci când:

Clientul trebuie să agrege date de la mai multe entități într-o singură solicitare (tipic în BFF, Backend pentru Frontend)
Clienții diferiți (mobil, web, tablou de bord) au nevoi foarte diferite de la aceleași date
Echipa are mai multe echipe frontend care necesită flexibilitate independentă de backend

GraphQL introduce o complexitate non-trivială:

Problema N+1 (rezolvat cu DataLoader, dar necesită înțelegere)
Memorare în cache mai complexă decât REST (nu puteți face memorarea în cache HTTP a GET-urilor)
Preluare excesivă ascunsă: un client care solicită prea multe câmpuri poate descărca baza de date
Autorizare mai complexă la nivel de câmp

gRPC: Conducătorul microserviciilor

gRPC nu este pentru toată lumea, ci pentru comunicațiile de la serviciu la serviciu în arhitecturile microservicii și a devenit standardul de facto în sistemele de înaltă performanță. Cifrele confirmă:

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

Suplimentul de configurare gRPC (fișier .proto, generare de cod, compilator Protobuf) este justificat atunci când performanța și siguranța tipului contractului sunt critice, de obicei pentru servicii care sunt numite de sute sau de mii de ori pe secundă.

tRPC: Revoluția TypeScript

tRPC și-a găsit nișa și o domină: aplicații TypeScript full-stack în monorepo unde frontend și backend partajează baza de cod. Creșterea cu 15% a rolurilor TypeScript nu este aleatoriu: este răspunsul la una dintre cele mai frustrante probleme ale dezvoltării web moderne.

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

Limitare importantă a tRPC

tRPC funcționează NUMAI cu TypeScript pe ambele părți. Nu îl puteți folosi pentru API-uri publice (unde clienții sunt în limbi diferite) sau pentru comunicații între microservicii în limbi eterogene. Este conceput pentru monorepo-uri TypeScript unde aveți control complet atât frontend-ul cât și backend-ul.

Arhitectură hibridă: Folosind mai multe protocoale împreună

În lumea reală, sistemele complexe combină adesea mai multe protocoale, fiecare în cazul în care excelează:

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

Acest model este extrem de comun în companiile de tehnologie în 2026:

Odihnește-te spre exterior pentru interoperabilitate cu clienți eterogene
tRPC pentru tabloul de bord intern TypeScript, maximizând siguranța DX și a tipului
gRPC între microservicii pentru contracte de execuție și contracte formale

Lista de verificare pentru selecția protocolului

Înainte de a te decide, răspunde la aceste întrebări:

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

Concluzii și pașii următori

Nu există un „câștigător” universal între REST, GraphQL, gRPC și tRPC. Alegerea corectă depinde de cine consumă API-ul, cerințele de performanță, limbajul echipei și complexitatea datelor. Vestea bună: nu trebuie să alegeți doar una - arhitecturi hibride care combină mai multe protocoale sunt norma în sistemele de întreprindere moderne.

Următoarele articole din această serie analizează fiecare protocol în detaliu. În continuare e REST în 2026: cele mai bune practici, versiunea și modelul de maturitate Richardson — a aprofundare despre cum să implementați corect REST, de ce majoritatea „API-urilor REST” nu sunt cu adevărat RESTful și, la fel ca OpenAPI 3.1, rezolvă problema contractului formal.

Seria: API Design — Comparație REST, GraphQL, gRPC și tRPC

Articolul 1 (acesta): Peisajul API în 2026 — Matricea decizionale
Articolul 2: REST în 2026 — Cele mai bune practici, versiunea și modelul de maturitate Richardson
Articolul 3: GraphQL — Limbajul de interogare, soluția și problema N+1
Articolul 4: Federația GraphQL – Supergraph, Subgraph și Apollo Router
Articolul 5: gRPC — Protobuf, performanță și comunicare de la serviciu la serviciu
Articolul 6: tRPC — Tip Siguranță End-to-End fără generare de cod
Articolul 7: Webhooks — Modele, securitate și logică de reîncercare
Articolul 8: Versiune API - URI, antet și Politica de depreciere
Articolul 9: Limitarea ratei și limitarea — Algoritmi și implementări
Articolul 10: Arhitectură API hibridă – REST + tRPC + gRPC în 2026