API Gateway: ce este, ce probleme rezolvă, când nu îți trebuie

Un API gateway este un strat intermediar care stă între clienți și serviciile din spate, preluând responsabilități transversale, cum sunt autentificarea, limitarea ratei de cereri, rutarea și logging-ul, în locul fiecărui serviciu în parte. Pe scurt, rezolvă o problemă de duplicare: fără gateway, fiecare microserviciu trebuie să reimplementeze aceleași verificări.

Termenul a intrat în vocabularul arhitectural serios după 2014, odată cu proliferarea microserviciilor, dar conceptul există de mai mult timp sub forma reverse proxy-ului cu responsabilități extinse. Confuzia frecventă este că un API gateway ar fi întotdeauna un produs dedicat (Kong, AWS API Gateway, Tyk). Nu este. nginx configurat corect face deja munca unui gateway de bază pentru multe echipe.

Ce este un API gateway mai exact?

Un punct de intrare unic (single entry point) prin care trec toate cererile externe înainte să ajungă la serviciile din spate. Responsabilitățile clasice ale unui API gateway sunt:

• Terminarea TLS. Criptarea se oprește la gateway; traficul intern poate rula necriptat sau cu mTLS, după politica echipei.
• Autentificare și autorizare de nivel de rețea. Verificarea JWT-ului sau a cheii de API înainte ca cererea să atingă serviciul. Serviciul primește identitatea validată, nu tokenul brut.
• Rate limiting centralizat. O singură politică aplicată tuturor serviciilor, fără să fie reimplementată în fiecare.
• Routing și load balancing. Cererea pentru /api/users merge la serviciul de utilizatori, cererea pentru /api/orders merge la serviciul de comenzi, după reguli de routing declarate în gateway.
• Logging și tracing centralizat. Fiecare cerere este înregistrată o singură dată, la intrare, cu toate metadatele relevante, fără coordonare între servicii.
• Transformare de protocol. Conversie de la REST la gRPC, injecție de headere, redenumire de parametri, fără să atingi codul serviciului.

Care sunt problemele pe care le rezolvă?

Problema fundamentală este duplicarea de cod transversal. Fiecare microserviciu nou trebuie să implementeze autentificarea, să aplice rate limiting, să producă log-uri structurate și să expună metrici pentru observabilitate. Fără un punct central, o schimbare de politică (de exemplu, o nouă regulă de rate limiting) se propagă în zece repo-uri, cu zece deploys coordonate.

Problemele concrete pe care un gateway le rezolvă:

• Inconsistență de securitate. Un serviciu nou apărut în echipă a omis verificarea JWT-ului. Fără gateway, tot traficul ajunge direct la el. Cu gateway, verificarea are loc o singură dată, centralizat, înainte ca cererea să plece mai departe.
• Lipsa de vizibilitate cross-service. Când o cerere traversează patru servicii și eșuează, fără un punct central de logging nu știi unde s-a rupt. Gateway-ul generează un trace ID unic pe care fiecare serviciu îl propagă, permițând corelarea log-urilor.
• Expunerea prematură a topologiei interne. Fără gateway, clientul trebuie să știe adresele individuale ale serviciilor. Cu gateway, clientul cunoaște un singur host; reorganizarea internă a serviciilor nu necesită schimbări la client.
• Managementul versiunilor de API. Gateway-ul poate ruta /api/v1 la implementarea veche și /api/v2 la cea nouă în paralel, fără downtime pentru clienții pe versiunea anterioară.

Cum diferă proxy-ul clasic, gateway-ul și sidecar-ul?

Trei concepte care se suprapun dar rezolvă probleme diferite:

• Reverse proxy clasic. Rutează traficul după host sau cale, termină TLS, face load balancing. Nu înțelege semantica aplicației. nginx în configurație minimă este un reverse proxy.
• API gateway. Un reverse proxy care adaugă înțelegere a protocolului aplicației: știe ce înseamnă un JWT invalid, poate aplica politici per rută sau per client, poate transforma request-uri și response-uri, poate agrega răspunsuri din mai multe servicii într-unul singur. nginx cu module suplimentare sau produse dedicate precum Kong, Tyk sau AWS API Gateway intră în această categorie.
• Sidecar proxy. În loc de un gateway central, fiecare instanță de serviciu rulează alături de un proxy propriu care interceptează tot traficul de intrare și ieșire. Modelul este specific arhitecturilor service mesh (Istio, Linkerd). Aduce observabilitate și politici fine-grained fără modificarea codului aplicației, dar introduce overhead semnificativ de operare și are sens doar când ai zeci de servicii cu echipe separate.

Regula practică: pentru mai puțin de zece servicii, un gateway central este mai simplu de operat și de înțeles decât un service mesh. Sidecar-ul devine relevant când politicile de securitate diferă între fiecare pereche de servicii, nu doar la intrarea din exterior.

Cum folosim noi nginx ca strat de gateway?

La crawlerra, folosim nginx ca strat de intrare pentru produsele proprii, în principal pentru TLS termination, routing de cereri către backend-uri Spring Boot și access logging centralizat. Validarea autentificării (verificarea JWT-ului) și autorizarea granulară per resursă rămân în aplicație, nu în nginx; gateway-ul nu cunoaște logica de business sau permisiunile per utilizator.

Abordarea se potrivește profilului nostru: aplicații B2B cu trafic previzibil, un singur cluster de servicii per produs, fără nevoi de routing complex între zeci de echipe. Un produs dedicat de tip Kong sau Tyk ar introduce un nod suplimentar de operat, monitorizat și upgradeat, fără să rezolve o problemă reală pe volumul actual. Cât timp numărul de servicii rămâne mic și politicile de securitate sunt uniforme, nginx ca proxy cu reguli minime acoperă necesarul. Pentru toate produsele țintim același SLA de disponibilitate, iar simplitatea gateway-ului este una din componentele care contribuie la predictibilitatea acelui nivel de serviciu.

Când NU ai nevoie de un API gateway dedicat?

Un API gateway dedicat este over-engineering în cel puțin trei situații comune:

• Aplicație monolitică sau cu unu-două servicii. Logica transversală (autentificare, logging, rate limiting) trăiește natural în middleware-ul aplicației. Un gateway adaugă un hop de rețea și un nod de operat fără să reducă duplicarea, pentru că nu ai nimic de centralizat.
• Echipă mică cu politici uniforme. Dacă toate serviciile aplică aceeași politică de autentificare și aceleași reguli de rate limiting, middleware-ul comun dintr-o librărie partajată este mai simplu decât un gateway separat. Un gateway are sens când politicile diferă per client sau per serviciu, nu când sunt uniforme.
• Trafic intern între servicii. Un gateway stă în calea traficului public. Comunicarea serviciu-la-serviciu în rețeaua internă nu trece prin același gateway; adaugă latență și un punct de eșec suplimentar fără beneficii de securitate față de rețeaua privată. Apelurile interne între servicii se protejează cu mTLS sau cu autorizare de nivel de serviciu, nu prin redirecționarea prin gateway-ul public.

Anti-pattern-ul cel mai costisitor este gateway-ul omniscient: un gateway care a absorbit logică de business (reguli de eligibilitate, calcule de preț, validare de date de aplicație). Odată ce gateway-ul știe dacă un utilizator are voie sau nu la o anumită operație bazat pe statusul său de abonat, ai mutat logica de business din aplicație într-un strat de infrastructură imposibil de testat în izolare și greu de schimbat fără să afectezi toate echipele. Soluția nu este să extinzi gateway-ul, ci să-l ții la responsabilitățile de rețea și să lași deciziile de business în aplicație. Un orchestrator de automatizări sau serviciile de aplicație propriu-zise sunt locul potrivit pentru acea logică. Detalii despre cum se conectează limitarea ratei cu vizibilitatea sistemului găsești în intrarea despre rate limiting și în cea despre observabilitate.