Erilahendus AI Arendus

Miks WebPro veeb ei kasuta Drupalit

🎧 Kuula kõiki artikleid järjest

Kõik veebid ei vaja Drupalit ega isegi sisuhaldusplatvormi. WebPro enda veeb on näide olukorrast, kus lihtsam arhitektuur oli õige valik.

Drupal on suurepärane tööriist — õigel juhul

WebPro igapäevane töö on seotud Drupaliga. Kasutame seda keerukate veebide, portaalide, e-poodide ja infosüsteemide ehitamisel.

Aga Drupal ei ole lahendus igale probleemile.

Drupal on kõige tugevam siis, kui on vaja:

  • keerukat sisuhaldust;
  • mitut kasutajarolli;
  • töövooge ja õiguste haldust;
  • integratsioone;
  • regulaarset sisuloomet;
  • pikaajalist arendust.

Meie enda veeb ei vajanud neist peaaegu ühtegi.

Lehti on vähe, sisu muutub harva ja sisuhaldureid ei ole. Drupal oleks toonud kaasa andmebaasi, turvauuendused, moodulite halduse ja hoolduskoormuse ilma selge lisaväärtuseta.

Sellises olukorras ei olnud Drupal õige tööriist.

Miks mitte valmisraamistik?

Järgmine küsimus oli, kas kasutada mõnda populaarset staatilise veebisaidi generaatorit või frontend-raamistikku.

Valikute hulgas olid näiteks:

  • Hugo;
  • Astro;
  • Next.js;
  • Jekyll.

Need on kõik head tööriistad, kuid meie vajadus oli lihtsam.

Soovisime:

  • täielikku kontrolli väljundi üle;
  • minimaalset sõltuvuste hulka;
  • võimalikult lihtsat ehitusprotsessi;
  • võimalust mõista kogu süsteemi ilma kümnete teekide dokumentatsiooni lugemata.

Seetõttu ehitasime oma väikese staatilise generaatori Node.js abil.

Sisu on Markdown-failides ja ehituse tulemus on tavaline HTML.

Puudub andmebaas, puudub serveripoolne renderdamine ja puudub vajadus rakendusserveri järele.

Kui palju AI tegelikult aitas?

Selle projekti kõige huvitavam osa oli AI kasutamine.

Suur osa koodist sündis koostöös AI tööriistadega. Kasutuses olid nii Claude kui ka OpenAI mudelid.

AI aitas kirjutada:

  • generaatorikoodi;
  • komponente;
  • testiskripte;
  • SEO kontrolli;
  • infrastruktuuri konfiguratsiooni;
  • väiksemaid PHP lahendusi.

See ei tähenda, et AI ehitas veebi ise.

Tegelikkuses oli AI roll sarnane väga kiirele arendajale, kelle tööd tuleb pidevalt kontrollida.

Arhitektuurilised otsused jäid inimese teha:

  • mida üldse ehitada;
  • kuidas sisu struktureerida;
  • kuidas testida;
  • kuidas lahendada mitmekeelsus;
  • millised kompromissid valida.

AI kiirendas arendust märgatavalt, kuid ei eemaldanud vajadust tehniliste otsuste järele.

Kõige keerulisem osa polnud kood

Üllataval kombel ei kulunud kõige rohkem aega generaatorile.

Suurim ajakulu läks kvaliteedikontrolli peale.

Veebile on ehitatud automaatsed kontrollid, mis kontrollivad muu hulgas:

  • metaandmeid;
  • Open Graph märgendeid;
  • JSON-LD skeeme;
  • hreflang seoseid;
  • kontaktiplokke;
  • linkide terviklikkust;
  • WCAG põhinõudeid.

Testide kirjutamine võttis rohkem aega kui mitme tehnilise komponendi loomine.

Samas on just need testid põhjus, miks sisu lisamine on hiljem kiire ja turvaline.

AI nähtavus oli osa arhitektuurist

Traditsiooniliselt optimeeritakse veebilehti otsingumootorite jaoks.

Tänapäeval loevad veebisisu ka AI assistendid ja otsingumootorite AI süsteemid.

Seetõttu ehitasime veebi algusest peale nii, et see oleks hästi loetav:

  • inimestele;
  • otsingumootoritele;
  • AI süsteemidele.

Selleks kasutame:

  • struktureeritud andmeid;
  • selget HTML-struktuuri;
  • korrektseid metaandmeid;
  • sitemap'i;
  • robots.txt konfiguratsiooni;
  • llms.txt faili.

See ei garanteeri nähtavust, kuid aitab masinatel sisu paremini mõista.

Tulemus: lihtne, kiire ja hallatav

Kuna veeb on staatiline, puudub vajadus:

  • andmebaasi päringuteks;
  • renderdamiseks igal külastusel;
  • vahemälukihtide haldamiseks.

Lehed serveeritakse otse failisüsteemist.

See annab väga hea jõudluse ning vähendab tehnilist keerukust.

Lisaks on sisu haldamine lihtne:

  • uus artikkel tähendab uut Markdown-faili;
  • ehitus genereerib HTML-i automaatselt;
  • avaldamine on automatiseeritud.

Kas selline lahendus sobib kõigile?

Ei.

Tegelikult ei sobi see enamusele organisatsioonidest.

Kui veebil on:

  • mitu sisuhaldurit;
  • keerukad õigused;
  • töövood;
  • e-pood;
  • integratsioonid;
  • sagedased sisumuudatused;

siis on Drupal sageli parem valik.

Erilahendus muutub mõistlikuks siis, kui:

  • vajadused on väga spetsiifilised;
  • sisu on suhteliselt staatiline;
  • organisatsioonil on tehniline kompetents süsteemi hooldada.

Kokkuvõte

WebPro veeb ei kasuta Drupalit mitte sellepärast, et Drupal oleks halb valik.

Vastupidi.

Drupal on meie peamine tööriist keerukate veebide ehitamisel.

Lihtsalt selle konkreetse veebisaidi vajadused olid teistsugused.

Meile oli oluline:

  • maksimaalne lihtsus;
  • minimaalne sõltuvuste arv;
  • väga hea jõudlus;
  • täielik kontroll arhitektuuri üle.

Sellises olukorras osutus väike erilahendus kõige mõistlikumaks valikuks.

See ei ole universaalne lahendus, kuid selle projekti jaoks oli see õige lahendus.

Kaido Toomingas, WebPro tehniline juhtWebPro Company OÜ Tehniline juht: Kaido Toomingas

Vajad Drupal abi?

Kui artikkel puudutab sinu olukorda, ei pea kõike lõpuni lugema. Sinuga suhtleb päris inimene ja aitab järgmise sammuni jõuda.