Deus Figendi: eigenes CMS - Datenstruktur

Beitrag lesen

Serialisiert ja, JSON nein, Letzteres ist zwar für die eigene bildliche Vorstellung einer Datenhaltung und ~Strukturierung hilfreich, praktisch jedoch viel zu langsam. Diese Frage stellt sich umso mehr, je feiner Du die Abstraktion einer Seite machst, also die Zerlegung in Komponenten.

Du kannst an die Performance Zugeständnisse machen, wenn der Content geschrieben wird (Management), nicht jedoch bei der Auslieferung (User Request).

Naja, im Grunde spricht ja wenig dagegen beides zu machen, also eine Art "Cache"-Funktion. Fürs Backend gibt es hübsch zerlegte Daten, die man praktisch manipulieren kann und wenn man die verändert wird gleichzeitig eine HTML-Struktur erstellt, die aber niemals zurück gerechnet wird und bei Bedarf auch einfach zerstört werden kann (um sie neu anzulegen).
Wie dynamisch man sowas macht ist ja extrem variabel und kann von "Cache es beim Speichern" bis "cache es beim ersten Abruf" oder gar "cache es, wenn du gerade Zeit (idle) hast" gehen.
Aus dem Bauch heraus erscheint mir zweiteres am sinnvollsten, zzgl. einer Versions-Kontrolle. Also bei Aufruf:
Prüfen ob eine gecachte Version existiert
Prüfen ob irgendwelche Daten, die diese Version manipulieren (Inhalte, Templates... mglw. inline-JS oder so) jünger sind als die im Cache angelegte Version.
ggf. neu cachen
und ab dafür.

So verteilt man die Aktualisierung der Daten wenn zentrale Strukturen verändert werden imho ganz gut. Wenn ich so ein Template ändere, welches Einfluss auf X Datensätze hat muss ich eine Menge Zeug ersetzen. Da erscheint es praktischer wenn das nach und nach passiert beim Abruf. Zumal u.U. es sogar Inhalte geben mag, die eine "Zwischenversion" komplett überspringen, weil sie in Template-Version 2 (von 3) nie aufgerufen wurden. Ist ja auch nicht nötig, dass diese zwischendurch als HTML erstellt werden.

Typisches Gedankenbeispiel: Man verändert ein Template, testet es und ändert es nochmal, weil man einen Fehler gemacht hat/unzufrieden ist. Da wäre es ja Quatsch, dass beim Zwischenschritt alle Daten umgerechnet werden.

Und unterm Strich ist da noch die Last-Frage.
Wenn das Frontend eh von maximal zwei Benutzern gleichzeitig belastet wird und die Nutzdaten pro Seite typischerweise wenige sind kann man im Grund doch auch dynamisch die Inhalte erzeugen.
Ich stelle mir gerade die Website von Handwerksmeister Udo vor, auf dessen Page sich zweimal am Tag jemand verirrt und jeden zweiten Tag schaut sich jemand auch mehr als eine Seite an. Wenn die Generierung da eine halbe oder gar ganze Sekunde dauert ist das verkraftbar (zzgl. der Übertragungszeit selbstredend). Wenn man natürlich eine Seite hat, die ständig unter Last steht und da surfen im Schnitt hundert und zu Stoßzeiten dreihundert Leute drauf rum, dann ist das sicher nicht praktikabel (bzw. man braucht 'ne echte Wumpe als Server-Hardware und einen Webserver, der Multithreads beherrscht).

--
sh:( fo:| ch:? rl:( br:& n4:& ie:{ mo:} va:) de:µ_de:] zu:) fl:( ss:| ls:[ js:(