La un moment dat, în cele mai multe proiecte de site, cineva întreabă dacă site-ul ar trebui să fie „headless”. Întrebarea merită un răspuns adevărat, pentru că arhitectura pe care o alegi modelează costul a tot ce urmează: cât de rapid e site-ul, cum lucrează editorii, câte sisteme trebuie întreținute și cât costă o reproiectare peste trei ani. Articolul prezintă cele trei opțiuni în limbaj simplu, la ce e bună fiecare și de ce, pentru cele mai multe site-uri de firmă, o recomandăm pe cea din mijloc.
Clasic: Drupal randează fiecare pagină
În modelul clasic, Drupal stochează conținutul și produce și HTML-ul fiecărei pagini, prin stratul său de teme. Așa a funcționat platforma în primele două decenii, și rămâne un mod perfect valabil de a construi un site. Totul trăiește într-un singur sistem. Editorii previzualizează exact ce vor vedea vizitatorii. Cache-ul e simplu, motoarele de căutare primesc pagini complete, și există o singură livrare, un singur set de jurnale și un singur lucru de actualizat.
Limitele lui apar când interfața trebuie să se simtă ca o aplicație. Filtrarea unui catalog fără reîncărcare, un formular în mai mulți pași care validează pe măsură ce scrii, un panou care se actualizează în timp real: sunt posibile în modelul clasic, dar fiecare tinde să devină un mic proiect personalizat lipit pe șabloane care n-au fost proiectate pentru asta. Rezultatul e adesea un site în care paginile simple sunt curate, iar cele interactive sunt fragile.
Headless: Drupal ca API de conținut
În modelul headless, Drupal stochează și administrează conținutul, dar nu randează nimic. O aplicație frontend separată, de obicei construită cu un framework JavaScript și livrată pe propria infrastructură, preia conținutul printr-un API și produce paginile. Atracția e reală: echipa de frontend lucrează în instrumente pe care le cunoaște, interfața poate fi la fel de dinamică ca orice aplicație, iar același conținut poate alimenta un site, o aplicație mobilă și un ecran dintr-un magazin, dintr-o singură sursă.
Costurile sunt și ele reale, și sunt cele care tind să fie descoperite târziu. Acum sunt două aplicații de construit, găzduit, securizat, monitorizat și actualizat, pe două calendare de lansări. Editorii pierd previzualizarea, pentru că sistemul care ține conținutul nu e cel care îl afișează, iar reconstruirea acelei previzualizări e un proiect în sine. Fiecare funcție pe care Drupal o oferă gratis pe o pagină randată, cum ar fi cache-ul, controlul accesului la nivel de randare, tratarea formularelor, traducerile și structurile de meniu, trebuie reconstruită sau ocolită în frontend. Iar cele două sisteme trebuie ținute în pas pentru totdeauna, un cost de coordonare care nu dispare niciodată.
Headless e răspunsul potrivit pentru unele organizații: cele cu mai multe canale care au cu adevărat nevoie de același conținut, sau cu o echipă de frontend care va deține o aplicație separată ca ocupație principală. Pentru o firmă al cărei canal principal e site-ul, înseamnă de obicei să plătești două sisteme ca să obții unul.
Hibrid: componente moderne în interiorul Drupal
A treia opțiune păstrează Drupal drept sistemul unic care randează paginile, dar înlocuiește stratul tradițional de teme cu o bibliotecă de componente scrise în React. Drupal randează fiecare componentă pe server, astfel că pagina ajunge completă, rapidă și indexabilă. Browserul activează apoi aceleași componente acolo unde e nevoie de interacțiune, astfel că un catalog filtrabil, un formular dinamic sau un panou se comportă ca o aplicație fără un al doilea backend.
Așa construim noi, prin frontend-ul nostru bazat pe componente. Efectele practice sunt cele pe care oamenii le vor de la headless, fără costurile lui suplimentare. Editorii își păstrează previzualizarea, pentru că Drupal produce în continuare pagina. Permisiunile, traducerile, cache-ul și formularele vin în continuare de la platformă. Există o singură livrare și un singur calendar de actualizări. Iar interfața poate fi cât de bogată e nevoie, pentru că fiecare bucată din ea e o componentă reală, cu propria stare, propriile teste și propriul contract de accesibilitate. Site-urile construite așa se simt ca software și costă cât costă un site de rulat.
Cum alegi
Câteva întrebări lămuresc cele mai multe cazuri.
- Câte canale? Un site, poate cu o zonă de client: hibrid. Un site plus o aplicație nativă plus ecrane în magazin, toate arătând același conținut: headless merită luat serios în calcul, deși hibridul, cu stratul de API al Drupal servind celelalte canale, acoperă adesea situația.
- Cine întreține frontend-ul? O echipă dedicată de frontend care va deține o aplicație separată: headless e viabil. O agenție sau o echipă mică care întreține întregul site: hibridul ține totul într-un singur loc.
- Cât de interactivă e interfața? În mare pagini cu câteva formulare: clasicul e suficient, hibridul e mai confortabil. Ecrane de aplicație peste tot: hibrid sau headless, iar hibridul e mai ieftin.
- Cât de importantă e previzualizarea editorială? Dacă editorii trebuie să vadă exact ce publică, clasicul și hibridul o oferă; headless trebuie s-o reconstruiască.
- Care e bugetul de mentenanță? Două aplicații costă cam dublu de ținut la zi. Cifra asta singură decide multe proiecte.
Calea de mijloc nu e un compromis
E tentant să vezi hibridul ca o soluție la jumătatea drumului între cele două opțiuni „pure”. În practică e opțiunea care ia ce e mai bun din fiecare: simplitatea unui singur sistem, din clasic, și interfața modernă, din headless, fără fragilitatea primului sau dublarea celui de-al doilea. Și lasă ușa deschisă. Un site hibrid are deja o bibliotecă de componente și un strat de API, așa că dacă un al doilea canal apare cu adevărat mai târziu, adăugarea unui consumator headless pentru acel canal e un pas modest, nu o reconstrucție.
Dacă cântărești aceste opțiuni pentru un proiect nou sau pentru o reproiectare, le discutăm cu plăcere cu site-ul tău concret în minte. Răspunsul potrivit depinde de canalele, echipa și bugetul tău, iar o oră de conversație îl face de obicei limpede.