Partea pe care
n-o vede nimeni.
Aici stă cea mai mare parte din complexitatea unui sistem și aproape toate motivele pentru care cade. Un backend bine făcut nu se remarcă niciodată; se remarcă doar lipsa lui, de obicei într-o zi aglomerată.
02 — Ce construim
Date care ajung unde trebuie, și când nu ajung se știe.
Partea de sub interfață: ce ține datele, ce le mută dintr-un sistem în altul și ce face când celălalt sistem nu răspunde.
- API-uri și servicii
- REST și GraphQL scrise ca să fie folosite de altcineva: documentate, cu erori care spun ce s-a întâmplat, și versionate, ca o schimbare la noi să nu rupă integrarea altcuiva.
- Baze de date
- Scheme PostgreSQL și MySQL gândite înaintea codului, nu adaptate după el. Cu indecși puși unde se caută efectiv și cu migrări care se pot da înapoi.
- Integrări cu sisteme terțe
- Plăți, facturare, curierat, identitate, ERP, programele de contabilitate pe care le plătiți deja. Inclusiv cele care au documentația veche sau nu au deloc.
- Automatizări
- Munca repetitivă care se face acum de mână, mutată în sarcini programate: rapoarte, sincronizări, import și export. Cu jurnal, ca să se poată vedea ce a rulat și ce a ieșit.
- Migrări de date
- Mutarea dintr-un sistem vechi în unul nou, cu verificare de potrivire înainte și după. Datele care nu se potrivesc se raportează, nu se pierd tăcut.
Cu ce lucrămJava · Spring Boot · Node.js · Python · PostgreSQL · MySQL · REST · GraphQL
03 — Când are sens
Semnele că aici e problema.
- Două programe care ar trebui să vorbească nu vorbesc, iar cineva copiază date dintr-unul în altul.
- Comenzile sau facturile se pierd ocazional și nimeni nu poate spune unde.
- Orice modificare la API rupe ceva în altă parte, așa că nu se mai modifică nimic.
- Raportul de la sfârșitul lunii se face de mână, din trei surse care nu dau aceeași cifră.
- Baza de date a crescut și nimeni din echipă nu mai știe sigur ce e în ea.
04 — Cum lucrăm
Ce tratăm și de obicei se uită.
Ce se întâmplă când celălalt sistem tace
Orice integrare depinde de un serviciu care într-o zi nu va răspunde. Reîncercări, așteptare crescătoare și cereri care nu se execută de două ori dacă ajung de două ori — tratate de la început, nu după primul incident.
Migrări reversibile
Fiecare schimbare de schemă vine cu drumul înapoi scris odată cu ea. O publicare care nu poate fi anulată e o publicare care se amână, iar amânările se adună.
Urmă scrisă pentru fiecare cerere
Jurnale din care se poate reconstitui ce a făcut sistemul și de ce. Când clientul întreabă de ce nu i-a ajuns comanda, răspunsul se caută în date, nu se ghicește.
Datele sensibile tratate ca atare
Ce nu trebuie să apară în jurnale nu apare. Accesul se dă pe rol, secretele stau în afara codului, iar datele cu caracter personal se colectează doar cât e nevoie pentru ce face sistemul.
05 — Întrebări frecvente
Ce ne întreabă lumea despre partea asta.
Puteți lucra pe un backend scris de altcineva?
Da. Prima etapă e o citire a codului și a bazei de date, din care iese o listă scrisă cu ce e solid, ce e riscant și ce ar trebui atins întâi. De cele mai multe ori se poate lucra mai departe în ce există; rescrierea completă e rareori răspunsul corect și niciodată primul propus.
Sistemul cu care trebuie să ne integrăm nu are documentație. Se poate?
De obicei da, dar cu o etapă în plus. Se pornește de la ce se poate observa — cereri reale, răspunsuri reale — și se scrie documentația care lipsește, pe măsură ce se descoperă. E mai lent decât o integrare cu un serviciu bine documentat, și spunem asta din ofertă, nu pe parcurs.
Cum tratați datele cu caracter personal?
Se colectează doar ce e necesar pentru ce face sistemul, se păstrează cât are rost și nu ajung în jurnale. Unde e cazul, datele se separă, astfel încât un sistem care nu are nevoie de numele persoanei să nu îl primească. Nu e o listă de conformitate bifată la final, e felul în care se proiectează schema.
Ce se întâmplă cu integrările existente când schimbați API-ul?
Nu se rup. Versiunea veche rămâne în funcțiune în paralel cu cea nouă, cu un termen anunțat, ca cine se integrează cu voi să aibă timp să se mute. Schimbările care rup ceva fără preaviz sunt motivul pentru care multe firme nu-și mai ating API-ul deloc.
06 — Celelalte capabilități
Rareori vine una singură.
Cele patru se sprijină una pe alta: o aplicație are nevoie de un backend, backend-ul de un loc în care să ruleze, iar ce rulează deja de cineva care să îl țină în funcțiune. Luăm tot lanțul sau doar veriga care lipsește.
07 — Pasul următor
Aveți date care
se pierd pe drum?
Descrieți traseul lor și vă spunem unde se rupe — de multe ori nu e unde pare.