O opțiune pentru CMS: Cockpit

O opțiune pentru CMS: Cockpit

La proiectul curent am de făcut niște modificări la un site ce are ca backend Cockpit iar ca frontend Nuxt. Este o combinație tare… interesantă, dar nu mă pot decide dacă este interesant în sensul bun sau rău.

Am ajuns la concluzia – eu și o bună parte din internet, aparent – că, încet-încet, ne întoarcem la internetul anilor 2000: site-uri statice, simpliste. Iar generatoarele de genul ăsta (Nuxt, Hugo & co) pavează drumul.

Încă nu cred că suntem acolo, încă lipsesc funcționalități importante (căutare, formulare de contact), dar combinația asta de headless+consumator de API-uri ar putea fi de viitor, mai ales dacă se pune la punct o hidratare eficientă, agnostică de backend.

Din păcate, nu este genul de combinație ce poate fi evaluată (ușor) de un utilizator normal, non-tehnic, ci este ceva ce trebuie pregătit de cineva mai experimentat. Poate se va schimba asta pe viitor, nu știu…

3 Comentarii

Adrian a scris

Eu sunt mare fan static CMS. Folosim Jekyll peste tot.

E genial sa si partea de date intr-un yaml si iti generezi de acolo de exemplu pagini cu preturi sau orice forma de date. Am implementat recent schema.org FAQ si am pus Q&A in yaml si generez cu Jekyll partea de HTML + partea de JSON.

Cautarile nu sunt o problema, vezi aici: fleio.com/docs (mie jena sa recunosc ca programator batran, dar nu stiu de minune face acolo, dar merge. Ceva pe client, ca nu e nimic special pe server, doar statics CMS. Probabil ia ceva ceva JSON de pe server si sapa JS in el).

Oricum se pun in servicii externe prin AJAX comentarii, cautari, chiar si shopping carturi.

Diferenta de trafic pe care o poate duce un server intre static CMS si ceva dinamic e imensa! Adica faci fata la reddit/digg/cum-ii-mai-zice-acum effect cu un cont banal de hosting.

Ionuț Staicu a scris

@Adrian: Căutările nu sunt o problemă pe… un site mic. Eu aș fi vrut să conving un client să migreze pe un site static: multi-language (4 limbi) + ~3-4000 documente/limbă. Este nevoie de filtrări semi-complexe (e.g. între anii X-Y ȘI în categoria A dar nu în categoria B ȘI scrise de autorul C), deci este exclusă o funcționalitate pe frontend :(

Adrian a scris

@Ionuț Staicu: Atunci cred ca merge cu backend dinamic pentru date, editare cautare. Accesat prin AJAX la cautari.

Apoi, la build-ul static generezi YAML sau HTML cu date din baza de date. Noi facem asta, avem un PHP (ca era deja aplicatie PHP) care ia date din MySQL si genereaza YAML sau chiar HTML in unele situatii, iar procesul de build Jekyll (din Gitlab) la baga in site.

Cand te gandesti ca la inceputurile web-ului CGI-ul pornea un nou proces ca sa ruleze ceva PERL/etc. si sa scoata un HTML. Ei bine, nu suntem foarte departe acum :D, doar optimizari cu procese gata ruland, opcache, preloading. E chiar o nebunie ca nu sta HTML-ul ala gata generat pentru pagini care nu se schimba, si chiar daca se schimba, cum sunt stirile, il generezi la fiecare 5-10 secunde.

Adaugă un comentariurăspuns pentru

Poți adăuga bucăți de cod folosind [code]codul tău aici[/code], [js][/js], [php][/php] etc.

Link-urile în context sunt binevenite. Comentariile fără nume/email valid sunt șterse.
PS: Comentariul NU este editabil.

Acest sit folosește Akismet pentru a reduce spamul. Află cum sunt procesate datele comentariilor tale.

Site-ul blog.iamntz.com utilizează cookie-uri. Continuarea navigării presupune acceptarea lor. Mai multe informații.

windows apple dropbox facebook twitter