Merhaba! Ben

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.

İletişime Geç

Hakkımda

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.

Yeteneklerim

Analisi Dati & Modelli Previsionali

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

Süreç Otomasyonu

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

Özel Sistemler

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

Misyonum

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

Teknolojiyi Demokratikleştirmek

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.

BT ve İş Dünyasını Birleştirmek

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

Özel Çözümler Oluşturmak

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.

İşletmenizi Teknolojiyle Dönüştürün

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.

Konuşalım →

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.

İletişime Geç

Aklınızda bir proje mi var? Konuşalım! Formu doldurun, en kısa sürede dönüş yapacağım.

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

2026'da API Ortamı: REST, GraphQL, gRPC, tRPC — Ne Zaman Kullanılmalı Ne

Yeni bir projeye başlıyorsunuz ve API protokolünü seçmeniz gerekiyor. DİNLENMEK? GraphQL'mi? gRPC'yi mi? tRPC? 2026'da doğru cevap "en modern" ya da "herkesin kullandığı" değil, somut faktörlere bağlıdır: istemci türü (genel veya dahili), gecikme gereksinimleri, ekibin becerileri ve uygulamanın bağlamı.

Bu genel bakış bir pratik karar matrisi verilere dayalı gerçek: REST, arka uç iş ilanlarının %70'inde ve GraphQL'de görünüyor ve %25'e düşüyor (%32'den) 2023'te) yıllarca süren ilginin ardından tRPC, TypeScript rollerinde %15'e yükseldi ve gRPC hakim oldu Mikro hizmetlerde hizmetten hizmete iletişim. Bu sayıların neden var olduğunu anlayın doğru seçimi yapmanıza yardımcı olur.

Ne Öğreneceksiniz

REST, GraphQL, gRPC ve tRPC'nin temel özellikleri
Karar matrisi: hangi senaryo için hangi protokol
2026 benimseme verileri ve pazar eğilimleri
Her yaklaşımın gerçek ödünleşimleri
Birden fazla protokolü aynı mimaride birleştirme
API protokolünü seçmek için kontrol listesi

Dört Protokol: Hızlı Genel Bakış

Karar matrisine dalmadan önce her protokolün tam olarak ne yaptığını tanımlayalım:

REST (Temsili Devlet Transferi)

REST bir protokol değil, bir mimaridir. Kaynak olarak URL'ler içeren standart HTTP'yi temel alır, Eylemler olarak HTTP fiilleri (GET, POST, PUT, DELETE) ve baskın yük biçimi olarak JSON. REST'in resmi bir şeması yoktur (OpenAPI fiili bir standarttır, REST'in parçası değildir) orijinal), sorgu dili yoktur ve her uç nokta belirli bir kaynağı kullanıma sunar.

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

GrafikQL

GraphQL, istemcinin tam olarak hangi verileri belirttiği API'lere yönelik bir sorgu dilidir istiyor. Tek bir son nokta vardır (genellikle POST /graphql) ve müşteri bir mesaj gönderir İstenen verinin yapısını açıklayan sorgu. Plan resmi ve tipik bir sözleşmedir.

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

gRPC (Google Uzaktan Prosedür Çağrısı)

gRPC, ikili serileştirme için Protokol Arabelleklerini (Protobuf) ve aktarım olarak HTTP/2'yi kullanır. Hizmetler dosyalarda tanımlanır .protove istemci/sunucu kodu oluşturulur otomatik olarak. Ayrıca düşük gecikme süreli hizmetten hizmete iletişim için tasarlanmıştır.

// 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 Uzaktan Prosedür Çağrısı)

tRPC, istemci-sunucu ikilemini ortadan kaldıran bir TypeScript çerçevesidir: tanımlar Arka Uç TypeScript'leri, kod oluşturmaya gerek kalmadan doğrudan ön uçta mevcuttur. Ayrı bir ağ protokolü değil, standart HTTP kullanıyor, ancak uçtan uca güvenlik türü kullanıyor ve TypeScript derleyicisi tarafından garanti edilir.

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

Protokol seçimi şu faktörlere dayanmalıdır:

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: Neden %70'te kalıyor?

REST hakimdir çünkü evrensel ortak paydadır. Herhangi bir HTTP istemcisi tüketebilir bir REST API: curl, Postman, herhangi bir programlama dili. Bu çok önemli İstemcileri kontrol etmediğiniz genel API'ler.

REST'in 2026'daki somut faydaları:

HTTP yerel önbelleğe alma: GET /users/123 ve ekstra yapılandırma gerektirmeden tüm düzeylerde (CDN, tarayıcı, ters proxy) önbelleğe alınabilir
Olgun takımlama: Postman, Insomnia, Swagger UI, SDK oluşturucular — her şey REST ile çalışır
Hata ayıklama kolaylığı: standart bir HTTP isteğidir ve herhangi bir ağ aracında okunabilir
Tasarım gereği vatansız: her istek bağımsızdır ve yatay ölçeklendirme için idealdir
Endüstri Standardı: REST'i tüm ekipler bilir, öğrenme eğrisini azaltır

REST'in gerçek sınırları:

Aşırı getirme: GET /users müşteri yalnızca 2 tane istese bile tüm alanları döndürür
Yetersiz getiriliyor: kullanıcıya + siparişlere + ürünleri göstermek için genellikle 3 ayrı API çağrısı gerekir
Resmi tip yok: OpenAPI olmadan, API sözleşmesi ve yalnızca metinsel belgeler
Karmaşık versiyonlama: /v1 vs /v2 uç nokta çoğalmasına yol açar

GraphQL: Heyecan Verici Ölçeklendirilmiş, Niş Onaylandı

GraphQL'in benimsenmesindeki %32'den %25'e düşüş bir olgunlaşmayı yansıtıyor: yıllar süren deneyimden sonra her şeyin cevabı olarak kullanıldığında topluluk GraphQL'in senaryolarda üstün olduğunu fark etti spesifiktir ancak basit senaryolarda orantısız karmaşıklığa neden olur.

GraphQL şu durumlarda gerçekten parlıyor:

Müşteri, birden çok varlıktan gelen verileri tek bir istekte toplamalıdır (BFF'de tipik olarak Ön Uç için Arka Uç)
Farklı müşterilerin (mobil, web, kontrol paneli) aynı verilere yönelik çok farklı ihtiyaçları vardır
Ekibin, arka uçtan bağımsız esneklik gerektiren birden fazla ön uç ekibi var

GraphQL önemsiz olmayan bir karmaşıklık sunar:

N+1 problemi (DataLoader ile çözüldü ancak anlaşılması gerekiyor)
REST'ten daha karmaşık önbelleğe alma (GET'lerin HTTP önbelleğe alınmasını yapamazsınız)
Gizli aşırı alım: Çok fazla alan isteyen bir istemci veritabanını boşaltabilir
Daha karmaşık alan düzeyinde yetkilendirme

gRPC: Mikro Hizmetlerin Hükümdarı

gRPC herkese yönelik değildir ancak mikro hizmet mimarilerinde hizmetten hizmete iletişim içindir ve yüksek performanslı sistemlerde fiili standart haline gelmiştir. Rakamlar bunu doğruluyor:

// 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 kurulum ek yükü (.proto dosyası, kod oluşturma, Protobuf derleyicisi) haklıdır Sözleşmenin performansı ve tür güvenliği kritik olduğunda, genellikle hizmetler için saniyede yüzlerce veya binlerce kez çağrılanlar.

tRPC: TypeScript Devrimi

tRPC kendi nişini buldu ve ona hakim oluyor: monorepo'da tam yığın TypeScript uygulamaları ön uç ve arka ucun kod tabanını paylaştığı yer. TypeScript rollerindeki %15'lik büyüme rastgele: modern web geliştirmedeki en sinir bozucu sorunlardan birinin cevabıdır.

// 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'nin önemli sınırlaması

tRPC YALNIZCA her iki tarafta da TypeScript ile çalışır. Herkese açık API'ler için kullanamazsınız (istemcilerin farklı dillerde olduğu durumlarda) veya mikro hizmetler arasındaki iletişimler için heterojen diller. Tam kontrole sahip olduğunuz TypeScript monorepo'ları için tasarlanmıştır hem ön uç hem de arka uç.

Hibrit Mimari: Birden Fazla Protokolü Bir Arada Kullanmak

Gerçek dünyada, karmaşık sistemler genellikle birden fazla protokolü birleştirir ve her biri üstünlük sağlar:

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

Bu kalıp 2026'da teknoloji şirketlerinde oldukça yaygın:

REST dışarı doğru heterojen istemcilerle birlikte çalışabilirlik için
Dahili kontrol paneli için tRPC TypeScript, DX ve yazım güvenliğini en üst düzeye çıkarır
Mikro hizmetler arasında gRPC performans ve resmi sözleşmeler için

Protokol Seçimi Kontrol Listesi

Karar vermeden önce şu soruları yanıtlayın:

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

Sonuçlar ve Sonraki Adımlar

REST, GraphQL, gRPC ve tRPC arasında evrensel bir "kazanan" yoktur. Doğru seçim API'yi kimin kullandığına, performans gereksinimlerine, ekip diline ve verilerin karmaşıklığı. İyi haber: Yalnızca bir tanesini seçmek zorunda değilsiniz; hibrit mimariler birden fazla protokolü birleştiren modern kurumsal sistemlerde normdur.

Bu serideki sonraki makaleler her protokolü ayrıntılı olarak ele almaktadır. Sonraki e 2026'da REST: En İyi Uygulama, Sürüm Oluşturma ve Richardson Olgunluk Modeli - bir REST'in nasıl doğru şekilde uygulanacağına ilişkin ayrıntılı inceleme, neden çoğu "REST API'si" gerçek anlamda RESTful değiller ve OpenAPI 3.1 gibi resmi sözleşme sorununu çözüyorlar.

Seri: API Tasarımı — REST, GraphQL, gRPC ve tRPC Karşılaştırması

Madde 1 (bu): 2026'da API Ortamı — Karar Matrisi
Makale 2: 2026'da REST - En İyi Uygulama, Sürüm Oluşturma ve Richardson Olgunluk Modeli
Makale 3: GraphQL — Sorgu Dili, Çözümleyici ve N+1 Sorunu
Madde 4: GraphQL Federasyonu - Üst Grafik, Alt Grafik ve Apollo Yönlendirici
Madde 5: gRPC — Protobuf, Performans ve Hizmetten Hizmete İletişim
Madde 6: tRPC — Kod Oluşturmadan Uçtan Uca Güvenlik Türü
Madde 7: Web Kancaları — Kalıplar, Güvenlik ve Yeniden Deneme Mantığı
Madde 8: API Sürümü Oluşturma - URI, Başlık ve Kullanımdan Kaldırma Politikası
Madde 9: Hız Sınırlama ve Azaltma - Algoritmalar ve Uygulamalar
Makale 10: Hibrit API Mimarisi — 2026'da REST + tRPC + gRPC