Există un fel de programare care rareori e pomenit în cursurile de informatică. Nu e glamuros. Nu implică inventarea unui nou algoritm de sortare sau construirea unei interfețe frumoase. Îi spunem cod de lipici (glue code), iar în economia API-urilor de azi e exact locul în care e cel mai probabil să se rupă afacerea ta.
Pe măsură ce tehnologiile se maturizează, componentele de bază devin commodity. Nu scrii un motor de baze de date; se ocupă Postgres. Nu construiești un procesator de plăți; folosești Stripe. Partea grea a ingineriei moderne nu e construirea pieselor individuale. E să faci zece platforme externe să comunice între ele în siguranță.
Concluzii cheie
- Pe măsură ce componentele de bază devin commodity (Postgres, Stripe), valoarea se mută spre codul de lipici care conectează sistemele.
- Codul de lipici trebuie să rezolve trei probleme grele: traducerea de domeniu, idempotența și degradarea elegantă.
- Platforme diferite definesc aceeași entitate diferit, așa că o integrare trebuie să mapeze realități care nu sunt de acord între ele.
- Idempotența (chei unice de tranzacție) e ceea ce împiedică un webhook reîncercat să expedieze două comenzi.
- Pentru agenții AI, codul de lipici determinist e guardrail-ul care validează fiecare apel al modelului înainte să atingă datele tale.
De ce se rup afacerile la nivelul codului de lipici?
Pentru că majoritatea dezvoltatorilor tratează integrările ca pe simple țevi de date. Scriu o funcție care ia un payload JSON din Sistemul A și îl împinge în Sistemul B, merge pe laptop și se livrează. Asta e capcana. Când conectezi sisteme distribuite, nu doar muți date, ci gestionezi stare distribuită peste rețele pe care nu le controlezi. Codul de lipici bun trebuie să rezolve trei probleme cu adevărat grele.
Cum sincronizezi sisteme care nu sunt de acord asupra realității?
Faci traducere de domeniu și o aplici cu exactitate. Fiecare unealtă SaaS are o altă presupunere despre lume: Stripe crede că un "client" e o entitate de plată, Salesforce crede că un "client" e o entitate din pipeline-ul de vânzări, iar baza ta de date crede că un "client" e o înregistrare de autentificare.
Când sincronizezi aceste sisteme și maparea nu e exactă, te alegi cu înregistrări de facturare orfane și cu o corupere silențioasă a datelor. Codul de lipici trebuie să impună logica de business peste sisteme care nu sunt de acord între ele, ceea ce e mult mai greu decât să muți un payload JSON dintr-un loc în altul.
Cum supraviețuiești defecțiunilor de rețea?
Cu idempotență. Rețelele cad, API-urile dau timeout și webhook-urile ajung cu întârziere. Dacă un webhook de plată Stripe dă timeout, Stripe îl reîncearcă peste câteva minute, iar codul de lipici naiv procesează acea reîncercare ca pe un eveniment nou-nouț, expediind clientului două produse în loc de unul.
Codul de lipici de nivel de producție folosește o cheie unică de tranzacție pe fiecare cale de execuție, astfel încât, dacă o cerere e procesată de două ori, starea sistemului se schimbă o singură dată. E neglamuros și duce tot greul.
Ce se întâmplă când un API extern cade?
Codul de lipici rezilient absoarbe defecțiunea în loc să o paseze mai departe. Dacă integrarea cu CRM-ul cade, checkout-ul n-ar trebui să se prăbușească odată cu ea. Când un serviciu terț returnează un 500, codul nostru îl prinde, pune sarcina într-o coadă dead-letter și alertează stiva de monitorizare. Aplicația principală continuă să ruleze, iar sarcina eșuată se reîncearcă automat cu backoff exponențial odată ce serviciul își revine.
De ce contează asta și mai mult pentru agenții AI?
Pentru că modelele de limbaj sunt nedeterministe, iar codul de lipici e singurul guardrail determinist pe care îl ai. Un model va produce ocazional un apel greșit sau malformat. Singura cale sigură de a-l pune în producție e să-l împachetezi în cod de lipici solid ca o stâncă, folosind un contract precum Model Context Protocol (MCP), care validează fiecare cerere pe baza unei scheme stricte înainte să i se permită să atingă baza ta de date.
Cei mai buni ingineri din industrie nu sunt cei care rescriu bibliotecile standard. Sunt arhitecții de sisteme care pot lega o rețea fragilă de API-uri într-un singur motor fiabil, unul care nu pierde niciodată o sarcină, nu duplică niciodată o comandă și nu eșuează niciodată în tăcere.