Hi! I'm

Federico Calò

Software Developer | Technical Writer

I create modern web applications and custom digital tools to help businesses grow through technological innovation. My passion is combining computer science and economics to generate real value.

Contact Me

About Me

My passion for computer science was born at the Technical Commercial Institute of Maglie, where I discovered the power of programming and the fascination of creating digital solutions. From the start, I understood that computer science was not just code, but an extraordinary tool for turning ideas into reality.

During my studies in Business Information Systems, I began to interweave computer science and economics, understanding how technology can be the engine of growth for any business. This vision accompanied me to the University of Bari, where I obtained my degree in Computer Science, deepening my technical skills and passion for software development.

Today I put this experience at the service of businesses, professionals and startups, creating tailor-made digital solutions that automate processes, optimize resources and open new business opportunities. Because true innovation begins when technology meets the real needs of people.

My Skills

Data Analysis & Predictive Models

I transform data into strategic insights with in-depth analysis and predictive models for informed decisions

Process Automation

I create custom tools that automate repetitive operations and free up time for value-added activities

Custom Systems

I develop tailor-made software systems, from platform integrations to customized dashboards

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

December 2024

View

Master SQL

RoadMap.sh

Novembre 2024

View

Oracle Certified Foundations Associate

Oracle

October 2024

View

People Leadership Credential

Connect

Settembre 2024

💻 Languages & Technologies

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

The API Landscape in 2026: REST, GraphQL, gRPC, tRPC — When to Use What

You are starting a new project and need to choose the API protocol. REST? GraphQL? gRPC? tRPC? The right answer in 2026 is not "the most modern" or "the one everyone uses", but depends on concrete factors: the type of client (public vs internal), latency requirements, the skills of the team, and the context of the application.

This overview builds a practical decision matrix based on data real: REST appears in 70% of backend job postings, GraphQL and down to 25% (from 32% in 2023) after years of hype, tRPC grows to 15% in TypeScript roles, and gRPC dominates service-to-service communications in microservices. Understand why these numbers exist helps you make the right choice.

What You Will Learn

Fundamental features of REST, GraphQL, gRPC and tRPC
Decision matrix: which protocol for which scenario
2026 adoption data and market trends
Real trade-offs of each approach
How to combine multiple protocols in the same architecture
Checklist for choosing the API protocol

The Four Protocols: Quick Overview

Before delving into the decision matrix, let's define precisely what each protocol does:

REST (Representational State Transfer)

REST is an architecture, not a protocol. It is based on standard HTTP with URLs as resources, HTTP verbs (GET, POST, PUT, DELETE) as actions, and JSON as the predominant payload format. REST does not have a formal schema (OpenAPI is a de facto standard, not part of REST original), has no query language, and each endpoint exposes a specific resource.

// 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 is a query language for APIs where the client specifies exactly what data wants. There is a single endpoint (usually POST /graphql), and the client sends a query that describes the structure of the requested data. The scheme is the formal and typified 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 uses Protocol Buffers (Protobuf) for binary serialization and HTTP/2 as a transport. Services are defined in files .proto, and the client/server code is generated automatically. And designed for low-latency service-to-service communications.

// 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 a framework for TypeScript that eliminates the client-server dichotomy: the definitions Backend TypeScripts are directly available in the frontend without code generation. It is not a separate network protocol — it uses standard HTTP — but end-to-end type safety and guaranteed by the 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)

The 2026 Decision Matrix

The choice of protocol should be based on these factors:

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: Why it remains at 70%

REST dominates because it is the universal common denominator. Any HTTP client can consume a REST API: curl, Postman, any programming language. This is crucial for Public APIs where you don't control the clients.

The concrete benefits of REST in 2026:

HTTP native caching: GET /users/123 and cacheable at all levels (CDN, browser, reverse proxy) without extra configuration
Mature tooling: Postman, Insomnia, Swagger UI, SDK generators — everything works with REST
Ease of debugging: a standard HTTP request and readable in any networking tool
Stateless by design: each request is self-contained, ideal for horizontal scaling
Industry Standard: any team knows REST, it reduces the learning curve

The real limits of REST:

Over-fetching: GET /users returns all fields even if the client only wants 2
Under-fetching: to show user + orders + products often requires 3 separate API calls
No formal type: without OpenAPI, the API contract and only textual documentation
Complicated versioning: /v1 vs /v2 leads to endpoint proliferation

GraphQL: Hype Scaled, Niche Confirmed

The decline from 32% to 25% in GraphQL adoption reflects a maturation: after years of was used as the answer to everything, the community realized that GraphQL excels in scenarios specific but introduces disproportionate complexity in simple scenarios.

GraphQL really shines when:

The client must aggregate data from multiple entities in a single request (typical in BFF, Backend for Frontend)
Different clients (mobile, web, dashboard) have very different needs from the same data
The team has multiple frontend teams that require backend-independent flexibility

GraphQL introduces non-trivial complexity:

The N+1 problem (solved with DataLoader but requires understanding)
More complex caching than REST (you can't do HTTP caching of GETs)
Hidden over-fetching: A client requesting too many fields can dump the database
More complex field-level authorization

gRPC: The Ruler of Microservices

gRPC is not for everyone, but for service-to-service communications in microservice architectures and has become the de facto standard in high-performance systems. The numbers confirm it:

// 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 file, code generation, Protobuf compiler) is justified when the performance and type safety of the contract are critical, typically for services which are called hundreds or thousands of times per second.

tRPC: The TypeScript Revolution

tRPC has found its niche and is dominating it: full-stack TypeScript applications in monorepo where frontend and backend share the codebase. The 15% growth in TypeScript roles is not random: it's the answer to one of the most frustrating problems in modern web development.

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

Important limitation of tRPC

tRPC ONLY works with TypeScript on both sides. You can't use it for public APIs (where clients are in different languages) or for communications between microservices in heterogeneous languages. It is designed for TypeScript monorepos where you have complete control both the frontend and the backend.

Hybrid Architecture: Using Multiple Protocols Together

In the real world, complex systems often combine multiple protocols, each where it excels:

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

This pattern is extremely common in tech companies in 2026:

REST outward for interoperability with heterogeneous clients
tRPC for the internal dashboard TypeScript, maximizing DX and type safety
gRPC between microservices for performance and formal contracts

Protocol Selection Checklist

Before you decide, answer these questions:

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

Conclusions and Next Steps

There is no universal "winner" between REST, GraphQL, gRPC, and tRPC. The correct choice depends on who consumes the API, performance requirements, team language, and complexity of the data. The good news: You don't have to choose just one — hybrid architectures that combine multiple protocols are the norm in modern enterprise systems.

The next articles in this series delve into each protocol in detail. Next e REST in 2026: Best Practice, Versioning and the Richardson Maturity Model — a deep dive on how to implement REST correctly, why most "REST APIs" they are not truly RESTful, and like OpenAPI 3.1 it solves the formal contract problem.

Series: API Design — REST, GraphQL, gRPC, and tRPC Compared

Article 1 (this): The API Landscape in 2026 — Decision Matrix
Article 2: REST in 2026 — Best Practice, Versioning, and the Richardson Maturity Model
Article 3: GraphQL — Query Language, Resolver and the N+1 Problem
Article 4: GraphQL Federation — Supergraph, Subgraph and Apollo Router
Article 5: gRPC — Protobuf, Performance and Service-to-Service Communication
Article 6: tRPC — Type Safety End-to-End without Code Generation
Article 7: Webhooks — Patterns, Security and Retry Logic
Article 8: API Versioning — URI, Header and Deprecation Policy
Article 9: Rate Limiting and Throttling — Algorithms and Implementations
Article 10: Hybrid API Architecture — REST + tRPC + gRPC in 2026