こんにちは！

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.

お問い合わせ

自己紹介

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.

スキル

Analisi Dati & Modelli Previsionali

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

プロセス自動化

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

カスタムシステム

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

ミッション

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

テクノロジーの民主化

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とビジネスの融合

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

カスタムソリューション

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.

テクノロジーでビジネスを変革

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.

お問い合わせ →

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.

お問い合わせ

プロジェクトをお考えですか？お気軽にお問い合わせください。

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

2026 年の API ランドスケープ: REST、GraphQL、gRPC、tRPC — いつ何を使用するか

新しいプロジェクトを開始しようとしているので、API プロトコルを選択する必要があります。休む？グラフQL？ gRPC? tRPC? 2026年の正解は「最新のもの」でも「みんなが使っているもの」でもなく、具体的な要因によって異なります: クライアントのタイプ (パブリックか内部か)、レイテンシー要件、チームのスキルとアプリケーションのコンテキスト。

この概要は、 実践的な意思決定マトリックス データに基づいて real: バックエンドの求人情報の 70%、GraphQL に REST が使用され、32% から 25% に減少 2023 年) 長年の誇大宣伝の後、TypeScript ロールでは tRPC が 15% に増加し、gRPC が優勢マイクロサービスにおけるサービス間通信。なぜこれらの数字が存在するのかを理解する正しい選択をするのに役立ちます。

何を学ぶか

REST、GraphQL、gRPC、tRPC の基本機能
意思決定マトリックス: どのシナリオにどのプロトコルを使用するか
2026 年の導入データと市場動向
各アプローチの実際のトレードオフ
同じアーキテクチャ内で複数のプロトコルを組み合わせる方法
API プロトコルを選択するためのチェックリスト

4 つのプロトコル: 概要

決定マトリックスを詳しく調べる前に、各プロトコルが何を行うかを正確に定義しましょう。

REST (表現状態転送)

REST はプロトコルではなくアーキテクチャです。これは、リソースとして URL を使用する標準 HTTP に基づいており、アクションとして HTTP 動詞 (GET、POST、PUT、DELETE) が使用され、主なペイロード形式として JSON が使用されます。 REST には正式なスキーマがありません (OpenAPI は事実上の標準であり、REST の一部ではありません) オリジナル)、クエリ言語はなく、各エンドポイントは特定のリソースを公開します。

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

グラフQL

GraphQL は、クライアントがどのデータを正確に指定する API 用のクエリ言語です。欲しいです。エンドポイントは 1 つです (通常は POST /graphql)、クライアントは要求されたデータの構造を記述するクエリ。このスキームは、形式的かつ類型化された契約です。

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

gRPC (Google リモートプロシージャコール)

gRPC は、バイナリのシリアル化にプロトコルバッファー (Protobuf) を使用し、トランスポートとして HTTP/2 を使用します。サービスはファイルで定義されます .proto、クライアント/サーバーコードが生成されます自動的に。また、低遅延のサービス間通信向けに設計されています。

// 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 リモートプロシージャコール)

tRPC は、クライアントとサーバーの二分法を排除する TypeScript のフレームワークです。定義バックエンド TypeScript は、コード生成せずにフロントエンドで直接使用できます。これは別個のネットワークプロトコルではなく、標準の HTTP を使用しますが、エンドツーエンドのタイプセーフです。 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)

2026 年の意思決定マトリックス

プロトコルの選択は、次の要素に基づいて行う必要があります。

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: 70% にとどまる理由

REST が優勢なのは、それが普遍的な共通分母であるためです。あらゆる HTTP クライアントが消費できる REST API:curl、Postman、任意のプログラミング言語。これは、クライアントを制御しないパブリック API。

2026 年の REST の具体的なメリット:

HTTP ネイティブキャッシュ: /users/123 を取得し、追加の構成なしですべてのレベル (CDN、ブラウザ、リバースプロキシ) でキャッシュ可能
成熟したツール: Postman、Insomnia、Swagger UI、SDK ジェネレーター — すべてが REST で動作します
デバッグのしやすさ: 標準の HTTP リクエストであり、あらゆるネットワークツールで読み取り可能
設計によりステートレス: 各リクエストは自己完結型であり、水平スケーリングに最適です
業界標準: どのチームでも REST を知っているため、学習曲線が短縮されます

REST の本当の限界:

オーバーフェッチ: GET /users クライアントが 2 つだけを必要とする場合でも、すべてのフィールドを返します
アンダーフェッチ: ユーザー + 注文 + 製品を表示するには、多くの場合、3 つの個別の API 呼び出しが必要になります
正式なタイプなし: OpenAPI なし、API コントラクト、テキスト文書のみ
複雑なバージョン管理: /v1 vs /v2 エンドポイントの急増につながる

GraphQL: 誇大広告をスケールし、ニッチを確認

GraphQL の採用率が 32% から 25% に減少したのは、何年にもわたっての成熟を反映しています。すべてに対する答えとして使用されたため、コミュニティは GraphQL がシナリオで優れていることに気づきました。具体的ですが、単純なシナリオでは不釣り合いな複雑さが生じます。

GraphQL は次の場合に真価を発揮します。

クライアントは、単一のリクエストで複数のエンティティからのデータを集約する必要があります (BFF では通常、フロントエンドに対するバックエンド)
異なるクライアント (モバイル、Web、ダッシュボード) では、同じデータに対して非常に異なるニーズがあります。
チームにはバックエンドに依存しない柔軟性を必要とする複数のフロントエンドチームがいます

GraphQL には、重大な複雑さが伴います。

N+1 問題 (DataLoaderで解決しますが理解が必要です)
REST よりも複雑なキャッシュ (GET の HTTP キャッシュは実行できません)
隠れたオーバーフェッチ: クライアントが多すぎるフィールドを要求すると、データベースがダンプされる可能性があります
より複雑なフィールドレベルの認可

gRPC: マイクロサービスの支配者

gRPC はすべての人に適しているわけではありませんが、マイクロサービスアーキテクチャにおけるサービス間通信に適しています。高性能システムの事実上の標準となっています。数字がそれを裏付けています。

// 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 セットアップのオーバーヘッド (.proto ファイル、コード生成、Protobuf コンパイラー) は正当化されます。通常はサービスなど、コントラクトのパフォーマンスと型安全性が重要な場合これらは 1 秒間に数百回または数千回呼び出されます。

tRPC: TypeScript 革命

tRPC はニッチ市場を見つけ、それを支配しています: モノリポジトリのフルスタック TypeScript アプリケーションフロントエンドとバックエンドはコードベースを共有します。 TypeScript ロールの 15% の増加はそうではありませんランダム: これは、現代の Web 開発における最もイライラする問題の 1 つに対する答えです。

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

tRPC の重要な制限事項

tRPC は両側の TypeScript でのみ動作します。パブリック API には使用できません (クライアントが異なる言語を使用している場合)、またはマイクロサービス間の通信用異種言語。完全に制御できる TypeScript モノリポジトリ用に設計されていますフロントエンドとバックエンドの両方。

ハイブリッドアーキテクチャ: 複数のプロトコルを併用する

現実の世界では、複雑なシステムでは複数のプロトコルが組み合わされることが多く、それぞれのプロトコルが優れています。

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

このパターンは 2026 年のテクノロジー企業で非常に一般的です。

外側へのREST 異種クライアントとの相互運用性のため
内部ダッシュボードの tRPC TypeScript、DX とタイプセーフティを最大化
マイクロサービス間の gRPC パフォーマンスと正式な契約のため

プロトコル選択チェックリスト

決定する前に、次の質問に答えてください。

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

結論と次のステップ

REST、GraphQL、gRPC、tRPC の間には、普遍的な「勝者」は存在しません。正しい選択 API を使用する人、パフォーマンス要件、チームの言語、およびデータの複雑さ。良いニュース: 1 つだけを選択する必要はありません — ハイブリッドアーキテクチャ複数のプロトコルを組み合わせて使用することは、現代のエンタープライズシステムでは標準です。

このシリーズの次の記事では、各プロトコルについて詳しく説明します。次へ e 2026 年の REST: ベストプラクティス、バージョニング、および Richardson 成熟度モデル — REST を正しく実装する方法と、ほとんどの「REST API」が使用される理由について詳しく説明します。これらは真の RESTful ではなく、OpenAPI 3.1 と同様に、正式な契約の問題を解決します。

シリーズ: API 設計 — REST、GraphQL、gRPC、tRPC の比較

第 1 条 (本): 2026 年の API ランドスケープ — 意思決定マトリックス
記事 2: 2026 年の REST — ベストプラクティス、バージョニング、および Richardson 成熟度モデル
記事 3: GraphQL — クエリ言語、リゾルバー、および N+1 問題
第 4 条: GraphQL フェデレーション — スーパーグラフ、サブグラフ、および Apollo ルーター
第 5 条: gRPC — Protobuf、パフォーマンス、およびサービス間通信
第 6 条: tRPC — コード生成を必要としないエンドツーエンドのタイプセーフティ
第 7 条: Webhook — パターン、セキュリティ、および再試行ロジック
第 8 条: API のバージョン管理 — URI、ヘッダー、非推奨ポリシー
第 9 条: レート制限とスロットリング — アルゴリズムと実装
第 10 条: ハイブリッド API アーキテクチャ — 2026 年の REST + tRPC + gRPC