De Ce Am Reconstruit de la Zero
RestartiX a funcționat pe Strapi — un sistem popular open-source de gestionare a conținutului folosit ca backend. Ne-a ajutat să pornim rapid, dar pe măsură ce platforma a crescut, fisurile au devenit prea semnificative pentru a mai putea fi remediate.
Această pagină explică justificarea de business pentru reconstrucție și ce s-a schimbat.
Ce nu funcționa
| Domeniu | Înainte (Strapi) | După (Platforma RestartiX) |
|---|---|---|
| Viteză sub sarcină | Paginile se încetineau pe măsură ce mai mulți utilizatori se conectau simultan | Gestionează mii de utilizatori simultani fără degradare |
| Risc de securitate | Construit pe un framework cu un istoric de vulnerabilități și mii de pachete terțe | Construit de la zero cu cod extern minimal — suprafață de atac mai mică, mai ușor de auditat |
| Conformitate healthcare | Greu de demonstrat auditorilor că datele pacienților erau protejate — comportamentele ascunse ale framework-ului îngreunau urmărirea a ceea ce se întâmpla | Fiecare acțiune este înregistrată, fiecare acces la date este trasabil — pregătit pentru audit GDPR din prima zi, cu pregătire HIPAA integrată |
| Izolarea datelor | Datele unei clinici puteau teoretic să fie expuse alteia prin lacunele framework-ului | Bariere la nivel de bază de date între clinici — imposibil ca o clinică să vadă datele alteia, impus de baza de date însăși |
| Fiabilitate | O solicitare proastă sau lentă putea îngheța întregul server | Solicitările sunt izolate — o operațiune lentă nu blochează niciodată altele |
| Costul infrastructurii | Necesita ~500 MB per instanță de server — scump de scalat | ~20 MB per instanță — același buget suportă de 25× mai multă capacitate |
| Viteza de dezvoltare | Modificările erau riscante — efectele secundare ascunse însemnau că bug-urile ajungeau în producție | Erorile sunt detectate înainte de deployment — iterare mai rapidă cu mai puține regresii |
| Independența față de vendor | Blocat de roadmap-ul și limitările Strapi | Construit în Go — folosit de Uber, Cloudflare, Docker — rezervă largă de specialiști, fără vendor lock-in |
De ce nu am actualizat pur și simplu Strapi?
Arhitectura Strapi înseamnă că conformitatea, performanța și izolarea sunt fundamental limitate de modul în care funcționează framework-ul — nu de configurare. Atingerea conformității healthcare (GDPR, HIPAA) pe Strapi ar fi necesitat să luptăm împotriva framework-ului la fiecare pas.
O reconstrucție de la zero ne permite să:
- Proiectăm conformitatea — nu o adăugăm ulterior
- Deținem fiecare comportament — fără middleware black-box, fără rute expuse automat
- Scalăm eficient — binarul este de 25× mai mic și de 10× mai rapid la pornire
- Audităm totul — fiecare linie de cod este a noastră, fiecare cale de date este explicită
Ce am păstrat
Reconstrucția este tehnică, nu o resetare a produsului. Cinci ani de cunoaștere a domeniului — cum funcționează clinicile, ce au nevoie specialiștii, cum se comportă pacienții — au modelat fiecare decizie.
- Toată logica de business și fluxurile de lucru au fost păstrate și îmbunătățite
- Datele pacienților și ale clinicilor vor fi migrate din sistemul legacy într-o operațiune unică
- Experiența produsului se îmbunătățește, fundația operațională devine solidă
Decizia arhitecturală cheie
Sistemul anterior avea două servicii separate: backend-ul principal Strapi și un microserviciu de programare separat (Intakes). Existența a două servicii însemna:
- Autentificare duplicată
- Datele trebuiau sincronizate între două baze de date
- Bug-uri cauzate de sincronizare
- Două deployment-uri de gestionat
Le-am unificat într-unul singur. O bază de cod, o bază de date, un deployment. Motorul de programare rulează în același serviciu ca toate celelalte. Fără bug-uri de sincronizare. Fără autentificare duplicată. Fără strat de mapare.
Află mai mult
- Prezentare generală a sistemului → — Cum este structurată platforma
- Decizii tehnice cheie → — Raționamentul din spatele Go, PostgreSQL, Clerk și altele