Primul lucru despre care ne întreabă majoritatea clienților e viteza. "Site-ul nostru pare lent. Îl puteți face mai rapid?" Al doilea, de obicei o lună sau două mai târziu, e costul. "Fiecare modificare costă mai mult decât ne așteptam. Se poate face ceva și aici?"
Cele două întrebări sunt aproape mereu legate între ele, iar pe majoritatea site-urilor Drupal au același răspuns.
De ce a devenit scump modelul "site-ului modern"
În ultimii zece ani, o anumită rețetă a cucerit lumea Drupal: conținutul stă în Drupal, frontend-ul e o aplicație JavaScript separată, iar cele două comunică printr-un strat REST sau JSON:API. Atracția e de înțeles. Frontend-ul arată modern, backend-ul rămâne Drupal, iar fiecare jumătate poate fi dezvoltată de propriii ei specialiști.
Costul devine vizibil abia după un an sau doi. Fiecare modificare a unei pagini trece prin două echipe, două lansări și două seturi de note de versiune. Fiecare câmp nou al unui tip de conținut trebuie adăugat în backend, expus prin API, descris în sistemul de tipuri al frontend-ului și legat de componenta care îl afișează. O modificare care pe un site Drupal clasic dura o după-amiază ocupă acum aproape un sprint întreg. Într-un an, asta se adună: o linie reală în buget și întârzieri reale în planul tău de dezvoltare.
Nimic din toate astea nu înseamnă că arhitecturile decuplate sunt greșite. Înseamnă că sunt un compromis foarte specific: plătești o taxă constantă la fiecare modificare, iar în schimb poți refolosi același backend pentru mai multe frontend-uri (un site, o aplicație mobilă, o integrare cu un partener). Dacă ai o aplicație mobilă peste site-ul tău Drupal, taxa merită plătită. Dacă ai un singur site, aproape niciodată.
Ce facem noi în schimb
Construim site-uri în care frontend-ul și backend-ul împart o singură bază de cod. Paginile pe care le vezi în browser sunt componente React, moderne cu adevărat, rapide și interactive, dar trăiesc în interiorul Drupal, se randează pe server pentru prima afișare și primesc direct datele de care au nevoie, fără nicio cerere HTTP la mijloc.
Nu trebuie să te intereseze cum funcționează. Trebuie să te intereseze ce se schimbă.
Prima pagină se încarcă vizibil mai repede. Pentru că serverul randează conținutul vizibil, iar browserul nu mai așteaptă un al doilea drum prin rețea ca să îl completeze, timpul de la clic până la o pagină lizibilă coboară de regulă sub o secundă, înainte să apară nerăbdarea. Pe site-urile de lead-gen și e-commerce, numai îmbunătățirea asta mișcă de regulă conversia măsurabil, la câteva săptămâni de la lansare.
Navigarea între pagini pare instantanee. Odată încărcată prima pagină, treci prin site ca și cum ai schimba tab-urile într-o aplicație desktop: fără reîncărcare completă, fără pâlpâitul unei pagini goale. Din experiența noastră, asta cântărește cel mai mult la întrebarea "pare o companie serioasă?", mai mult decât oricâtă muncă de design vizual.
Cu același buget de dezvoltare primești mai multe funcționalități. O cerere care într-o arhitectură decuplată ar trece prin două baze de cod e la noi, de obicei, un proiect mult mai mic. Nu pentru că tastăm mai repede. Ci pentru că modificăm o singură bază de cod, rulăm o singură suită de teste și lansăm un singur lucru. Înmulțește economia asta cu un an de cereri mici și ajungi lejer la costul unei funcționalități complet noi.
E o singură echipă, nu două. Un singur project manager, un singur număr de telefon, o singură factură. Când trebuie schimbat ceva, nu trebuie să ghicești dacă e "un tichet de frontend" sau "un tichet de backend". E pur și simplu un tichet.
Funcționează pentru orice site?
Aproape întotdeauna, pentru tipul de site-uri pe care le construim: bogate în conținut, active editorial, un singur site per organizație, uneori cu o zonă de administrare sau un portal pentru clienți deasupra. Nu e răspunsul potrivit dacă frontend-ul tău e o aplicație mobilă nativă care doar împarte același backend Drupal cu site-ul, sau dacă organizația ta chiar are echipe separate de frontend și de backend, cu ritmuri proprii de lansare și specializări profunde. Îți putem spune dintr-o singură discuție în care tabără ești.
Pentru toți ceilalți, adică pentru majoritatea celor care ne scriu, abordarea cuplată se construiește mai repede, merge mai repede, se întreține mai ieftin și e mai ușor să găsești oameni pentru ea. Iar site-urile pe care le lansăm așa sunt cele mai rapide site-uri Drupal pe care le-am făcut vreodată.
Dacă asta e exact ce încerci de ceva vreme să scoți de la site-ul tău actual, îți arătăm cu drag cum arată unul de-al nostru. Pentru prima discuție nu ai nevoie de nicio specificație.