Caching Data in SvelteKit

Mein vorheriger Beitrag gab einen breiten Überblick über SvelteKit, wo wir sahen, was für ein großartiges Werkzeug es für die Webentwicklung ist. Dieser Beitrag wird davon abzweigen, was wir dort getan haben, und uns in das Lieblingsthema jedes Entwicklers vertiefen: Caching. Stellen Sie also sicher, dass Sie meinen letzten Beitrag gelesen haben, wenn Sie dies noch nicht getan haben. Der Code für diesen Beitrag ist auf GitHub verfügbar, ebenso wie eine Live-Demo.

In diesem Beitrag geht es ausschließlich um Datenhandling. Wir werden eine rudimentäre Suchfunktion hinzufügen, die die Abfragezeichenfolge der Seite modifiziert (mithilfe integrierter SvelteKit-Funktionen) und den Lader der Seite erneut auslöst. Anstatt jedoch nur unsere (imaginäre) Datenbank neu abzufragen, werden wir ein Caching hinzufügen, sodass die erneute Suche nach früheren Suchen (oder die Verwendung der Zurück-Taste) zuvor abgerufene Daten schnell aus dem Cache anzeigt. Wir werden uns ansehen, wie die Gültigkeitsdauer der zwischengespeicherten Daten gesteuert wird und, was noch wichtiger ist, wie alle zwischengespeicherten Werte manuell ungültig gemacht werden. Als Sahnehäubchen werden wir uns ansehen, wie wir die Daten nach einer Mutation clientseitig auf dem aktuellen Bildschirm manuell aktualisieren können, während wir den Cache immer noch leeren.

Dies wird ein längerer, schwierigerer Beitrag als die meisten meiner üblichen, da wir komplexere Themen behandeln. Dieser Beitrag zeigt Ihnen im Wesentlichen, wie Sie gängige Funktionen beliebter Datenwerkzeuge wie react-query implementieren. Anstatt jedoch eine externe Bibliothek zu verwenden, werden wir nur die Webplattform und SvelteKit-Funktionen nutzen.

Leider sind die Funktionen der Webplattform etwas niedriger angesiedelt, sodass wir etwas mehr Arbeit leisten müssen, als Sie vielleicht gewohnt sind. Der Vorteil ist, dass wir keine externen Bibliotheken benötigen, was dazu beiträgt, dass die Bundle-Größen schön klein bleiben. Verwenden Sie die hier gezeigten Ansätze bitte nicht, es sei denn, Sie haben einen guten Grund dafür. Caching ist leicht falsch zu machen, und wie Sie sehen werden, gibt es eine gewisse Komplexität, die sich in Ihrem Anwendungscode niederschlagen wird. Hoffentlich ist Ihr Datenspeicher schnell und Ihre Benutzeroberfläche ist gut genug, damit SvelteKit immer die Daten abruft, die es für eine bestimmte Seite benötigt. Wenn ja, lassen Sie es so. Genießen Sie die Einfachheit. Aber dieser Beitrag zeigt Ihnen einige Tricks für den Fall, dass dies nicht mehr der Fall ist.

Wo wir gerade von react-query sprechen, es wurde gerade für Svelte veröffentlicht! Wenn Sie sich also häufig auf manuelle Caching-Techniken verlassen, sollten Sie dieses Projekt unbedingt ausprobieren und sehen, ob es Ihnen helfen kann.

Einrichtung

Bevor wir beginnen, nehmen wir ein paar kleine Änderungen am Code vor, den wir zuvor hatten. Dies gibt uns einen Anlass, einige andere SvelteKit-Funktionen zu sehen und, was noch wichtiger ist, uns für den Erfolg vorzubereiten.

Zuerst verschieben wir das Laden unserer Daten aus unserem Lader in +page.server.js in eine API-Route. Wir erstellen eine Datei +server.js in routes/api/todos und fügen dann eine GET-Funktion hinzu. Das bedeutet, dass wir jetzt Anfragen (mit dem Standard-GET-Verb) an den Pfad /api/todos stellen können. Wir werden den gleichen Code zum Laden der Daten wie zuvor hinzufügen.

import { json } from "@sveltejs/kit";
import { getTodos } from "$lib/data/todoData";

export async function GET({ url, setHeaders, request }) {
  const search = url.searchParams.get("search") || "";

  const todos = await getTodos(search);

  return json(todos);
}

Als Nächstes nehmen wir den Seitenlader, den wir hatten, und benennen die Datei einfach von +page.server.js in +page.js (oder .ts, wenn Ihr Projekt mit TypeScript eingerichtet wurde) um. Dadurch wird unser Lader zu einem „universellen“ Lader anstelle eines Server-Laders. Die SvelteKit-Dokumentation erklärt den Unterschied, aber ein universeller Lader läuft sowohl auf dem Server als auch auf dem Client. Ein Vorteil für uns ist, dass der fetch-Aufruf zu unserem neuen Endpunkt direkt aus unserem Browser läuft (nach dem anfänglichen Laden) und die native fetch-Funktion des Browsers verwendet. Wir werden gleich ein standardmäßiges HTTP-Caching hinzufügen, aber vorerst rufen wir nur den Endpunkt auf.

export async function load({ fetch, url, setHeaders }) {
  const search = url.searchParams.get("search") || "";

  const resp = await fetch(`/api/todos?search=${encodeURIComponent(search)}`);

  const todos = await resp.json();

  return {
    todos,
  };
}

Fügen wir nun ein einfaches Formular zu unserer /list-Seite hinzu

<div class="search-form">
  <form action="/list">
    <label>Search</label>
    <input autofocus name="search" />
  </form>
</div>

Ja, Formulare können direkt auf unsere normalen Seitenlader abzielen. Nun können wir einen Suchbegriff in das Suchfeld eingeben, Enter drücken, und ein „search“-Begriff wird an die Abfragezeichenfolge der URL angehängt, was unseren Lader erneut ausführt und unsere To-Do-Elemente durchsucht.

Erhöhen wir auch die Verzögerung in unserer Datei todoData.js in /lib/data. Dies erleichtert es, zu sehen, wann Daten zwischengespeichert werden und wann nicht, während wir diesen Beitrag durcharbeiten.

export const wait = async amount => new Promise(res => setTimeout(res, amount ?? 500));

Denken Sie daran, dass der vollständige Code für diesen Beitrag vollständig auf GitHub verfügbar ist, falls Sie darauf verweisen müssen.

Grundlegendes Caching

Beginnen wir mit dem Hinzufügen von Caching zu unserem Endpunkt /api/todos. Wir kehren zu unserer Datei +server.js zurück und fügen unseren ersten Cache-Control-Header hinzu.

setHeaders({
  "cache-control": "max-age=60",
});

…was die gesamte Funktion dann so aussehen lässt

export async function GET({ url, setHeaders, request }) {
  const search = url.searchParams.get("search") || "";

  setHeaders({
    "cache-control": "max-age=60",
  });

  const todos = await getTodos(search);

  return json(todos);
}

Wir werden uns gleich mit der manuellen Invalidierung befassen, aber diese Funktion besagt lediglich, dass diese API-Aufrufe 60 Sekunden lang zwischengespeichert werden sollen. Setzen Sie dies auf beliebigen Wert, und je nach Anwendungsfall könnte auch stale-while-revalidate einen Blick wert sein.

Und schon werden unsere Abfragen zwischengespeichert.

Hinweis stellen Sie sicher, dass Sie das Kontrollkästchen, das das Caching in den Entwicklertools deaktiviert, abwählen.

Denken Sie daran, dass die Suchergebnisse, wenn Ihre anfängliche Navigation in der App die Liste ist, intern in SvelteKit zwischengespeichert werden. Erwarten Sie also nicht, etwas in den DevTools zu sehen, wenn Sie zu dieser Suche zurückkehren.

Was wird gecacht und wo

Unsere allererste, serverseitig gerenderte Ladung unserer App (vorausgesetzt, wir beginnen auf der Seite /list) wird auf dem Server abgerufen. SvelteKit serialisiert diese Daten und sendet sie an unseren Client. Darüber hinaus beobachtet es den Cache-Control Header in der Antwort und weiß, dass es diese zwischengespeicherten Daten für diesen Endpunktaufruf innerhalb des Cache-Fensters (das wir in unserem Beispiel auf 60 Sekunden gesetzt haben) verwenden soll.

Nach dieser anfänglichen Ladung, wenn Sie mit der Suche auf der Seite beginnen, sollten Sie Netzwerkanfragen von Ihrem Browser an die Liste /api/todos sehen. Wenn Sie nach Dingen suchen, nach denen Sie bereits gesucht haben (innerhalb der letzten 60 Sekunden), sollten die Antworten sofort geladen werden, da sie zwischengespeichert sind.

Was bei diesem Ansatz besonders cool ist, ist, dass diese Aufrufe, da es sich um Caching über das native Caching des Browsers handelt, (abhängig davon, wie Sie das Cache-Busting verwalten, das wir uns ansehen werden) auch nach dem Neuladen der Seite zwischengespeichert werden könnten (im Gegensatz zum anfänglichen serverseitigen Laden, bei dem der Endpunkt immer frisch aufgerufen wird, auch wenn dies innerhalb der letzten 60 Sekunden geschehen ist).

Offensichtlich können sich Daten jederzeit ändern, daher benötigen wir eine Möglichkeit, diesen Cache manuell zu leeren, was wir als Nächstes betrachten werden.

Cache-Invalidierung

Derzeit werden Daten 60 Sekunden lang zwischengespeichert. Egal was passiert, nach einer Minute werden frische Daten aus unserem Datenspeicher abgerufen. Möglicherweise wünschen Sie einen kürzeren oder längeren Zeitraum, aber was passiert, wenn Sie Daten mutieren und Ihren Cache sofort leeren möchten, damit Ihre nächste Abfrage aktuell ist? Wir lösen dieses Problem, indem wir einen Query-Busting-Wert zur URL hinzufügen, die wir an unseren neuen Endpunkt /todos senden.

Speichern wir diesen Cache-Busting-Wert in einem Cookie. Dieser Wert kann auf dem Server gesetzt, aber trotzdem vom Client gelesen werden. Sehen wir uns einige Beispielcode an.

Wir können eine Datei +layout.server.js ganz am Anfang unseres Ordners routes erstellen. Diese wird beim Start der Anwendung ausgeführt und ist ein perfekter Ort, um einen anfänglichen Cookie-Wert zu setzen.

export function load({ cookies, isDataRequest }) {
  const initialRequest = !isDataRequest;

  const cacheValue = initialRequest ? +new Date() : cookies.get("todos-cache");

  if (initialRequest) {
    cookies.set("todos-cache", cacheValue, { path: "/", httpOnly: false });
  }

  return {
    todosCacheBust: cacheValue,
  };
}

Sie haben möglicherweise den Wert isDataRequest bemerkt. Denken Sie daran, dass Layouts jederzeit neu ausgeführt werden, wenn Client-Code invalidate() aufruft oder wenn wir eine Server-Aktion ausführen (vorausgesetzt, wir schalten das Standardverhalten nicht aus). isDataRequest zeigt diese Neutrigungen an, und so setzen wir den Cookie nur, wenn dieser false ist; andernfalls senden wir das mit, was bereits vorhanden ist.

Das Flag httpOnly: false ist ebenfalls bedeutsam. Dies ermöglicht es unserem Client-Code, diese Cookie-Werte in document.cookie zu lesen. Dies wäre normalerweise ein Sicherheitsrisiko, aber in unserem Fall handelt es sich um bedeutungslose Zahlen, die uns das Caching oder Cache-Busting ermöglichen.

Cache-Werte lesen

Unser universeller Lader ist es, der unseren Endpunkt /todos aufruft. Dieser läuft auf dem Server oder dem Client, und wir müssen diesen Cache-Wert, den wir gerade eingerichtet haben, lesen, egal wo wir uns befinden. Es ist relativ einfach, wenn wir uns auf dem Server befinden: Wir können await parent() aufrufen, um die Daten von übergeordneten Layouts abzurufen. Aber auf dem Client müssen wir einigen unschönen Code verwenden, um document.cookie zu parsen.

export function getCookieLookup() {
  if (typeof document !== "object") {
    return {};
  }

  return document.cookie.split("; ").reduce((lookup, v) => {
    const parts = v.split("=");
    lookup[parts[0]] = parts[1];

    return lookup;
  }, {});
}

const getCurrentCookieValue = name => {
  const cookies = getCookieLookup();
  return cookies[name] ?? "";
};

Glücklicherweise müssen wir das nur einmal tun.

Senden des Cache-Wertes

Aber jetzt müssen wir diesen Wert an unseren Endpunkt /todos senden.

import { getCurrentCookieValue } from "$lib/util/cookieUtils";

export async function load({ fetch, parent, url, setHeaders }) {
  const parentData = await parent();

  const cacheBust = getCurrentCookieValue("todos-cache") || parentData.todosCacheBust;
  const search = url.searchParams.get("search") || "";

  const resp = await fetch(`/api/todos?search=${encodeURIComponent(search)}&cache=${cacheBust}`);
  const todos = await resp.json();

  return {
    todos,
  };
}

getCurrentCookieValue('todos-cache') hat eine Prüfung, ob wir uns auf dem Client befinden (durch Prüfung des Dokumententyps), und gibt nichts zurück, wenn wir es sind. Dann verwendet es den Wert aus unserem Layout.

Cache leeren

Aber *wie* aktualisieren wir diesen Cache-Busting-Wert, wenn wir ihn brauchen? Da er in einem Cookie gespeichert ist, können wir ihn von jeder Server-Aktion aus aufrufen.

cookies.set("todos-cache", cacheValue, { path: "/", httpOnly: false });

Die Implementierung

Von hier an geht es nur noch bergab; wir haben die harte Arbeit geleistet. Wir haben die verschiedenen Webplattform-Primitive behandelt, die wir benötigen, sowie wo sie hingehören. Nun lassen Sie uns Spaß haben und Anwendungscode schreiben, um alles zusammenzufügen.

Aus Gründen, die gleich klar werden, beginnen wir mit dem Hinzufügen einer Bearbeitungsfunktion zu unserer Seite /list. Wir fügen diese zweite Tabellenzeile für jedes Todo hinzu.

import { enhance } from "$app/forms";

<tr>
  <td colspan="4">
    <form use:enhance method="post" action="?/editTodo">
      <input name="id" value="{t.id}" type="hidden" />
      <input name="title" value="{t.title}" />
      <button>Save</button>
    </form>
  </td>
</tr>

Und natürlich müssen wir eine Formularaktion für unsere Seite /list hinzufügen. Aktionen können nur in .server-Dateien platziert werden, also fügen wir eine +page.server.js in unserem Ordner /list hinzu. (Ja, eine Datei +page.server.js kann neben einer Datei +page.js existieren.)

import { getTodo, updateTodo, wait } from "$lib/data/todoData";

export const actions = {
  async editTodo({ request, cookies }) {
    const formData = await request.formData();

    const id = formData.get("id");
    const newTitle = formData.get("title");

    await wait(250);
    updateTodo(id, newTitle);

    cookies.set("todos-cache", +new Date(), { path: "/", httpOnly: false });
  },
};

Wir erfassen die Formulardaten, erzwingen eine Verzögerung, aktualisieren unser Todo und, was am wichtigsten ist, leeren unseren Cache-Busting-Cookie.

Lassen Sie uns das ausprobieren. Laden Sie Ihre Seite neu, bearbeiten Sie dann eines der To-Do-Elemente. Sie sollten sehen, wie sich der Tabellenwert nach einem Moment aktualisiert. Wenn Sie im Netzwerk-Tab der DevTools nachsehen, sehen Sie einen Fetch zum Endpunkt /todos, der Ihre neuen Daten zurückgibt. Einfach und funktioniert standardmäßig.

Sofortige Updates

Was wäre, wenn wir den Fetch vermeiden wollen, der nach der Aktualisierung unseres To-Do-Elements stattfindet, und stattdessen das bearbeitete Element direkt auf dem Bildschirm aktualisieren wollen?

Dies ist nicht nur eine Frage der Leistung. Wenn Sie nach „Post“ suchen und dann das Wort „Post“ aus einem der To-Do-Elemente in der Liste entfernen, verschwinden diese nach der Bearbeitung aus der Liste, da sie nicht mehr in den Suchergebnissen dieser Seite enthalten sind. Sie könnten die Benutzererfahrung mit einer geschmackvollen Animation für das ausgehende To-Do verbessern, aber sagen wir, wir wollten die Ladefunktion der Seite nicht neu ausführen, aber dennoch den Cache leeren und das bearbeitete To-Do aktualisieren, damit der Benutzer die Bearbeitung sehen kann. SvelteKit macht das möglich – sehen wir uns an, wie!

Zuerst nehmen wir eine kleine Änderung an unserem Lader vor. Anstatt unsere To-Do-Elemente zurückzugeben, geben wir einen beschreibbaren Store zurück, der unsere To-Dos enthält.

return {
  todos: writable(todos),
};

Zuvor haben wir auf unsere To-Dos über die data-Eigenschaft zugegriffen, die wir nicht besitzen und nicht aktualisieren können. Aber Svelte lässt uns unsere Daten in eigenen Stores zurückgeben (vorausgesetzt, wir verwenden einen universellen Lader, was wir tun). Wir müssen nur noch eine weitere Anpassung an unserer /list-Seite vornehmen.

Anstatt diesem

{#each todos as t}

…das müssen wir tun, da todos selbst jetzt ein Store ist.

{#each $todos as t}

Jetzt werden unsere Daten wie zuvor geladen. Da todos jedoch ein beschreibbarer Store ist, können wir ihn aktualisieren.

Zuerst stellen wir eine Funktion für unser use:enhance-Attribut bereit.

<form
  use:enhance={executeSave}
  on:submit={runInvalidate}
  method="post"
  action="?/editTodo"
>

Dies wird vor dem Absenden ausgeführt. Schreiben wir das als Nächstes.

function executeSave({ data }) {
  const id = data.get("id");
  const title = data.get("title");

  return async () => {
    todos.update(list =>
      list.map(todo => {
        if (todo.id == id) {
          return Object.assign({}, todo, { title });
        } else {
          return todo;
        }
      })
    );
  };
}

Diese Funktion stellt ein data-Objekt mit unseren Formulardaten bereit. Wir geben eine asynchrone Funktion zurück, die nachdem unsere Bearbeitung abgeschlossen ist, ausgeführt wird. Die Dokumentation erklärt all dies, aber indem wir dies tun, schalten wir das Standard-Formularhandling von SvelteKit ab, das unseren Lader neu ausgeführt hätte. Genau das wollen wir! (Wir könnten das Standardverhalten leicht wiederherstellen, wie die Dokumentation erklärt.)

Wir rufen jetzt update auf unserem todos-Array auf, da es sich um einen Store handelt. Und das war's. Nach der Bearbeitung eines To-Do-Elements erscheinen unsere Änderungen sofort und unser Cache wird geleert (wie zuvor, da wir in unserer editTodo-Formularaktion einen neuen Cookie-Wert gesetzt haben). Wenn wir also suchen und dann zu dieser Seite zurückkehren, erhalten wir frische Daten von unserem Lader, die alle aktualisierten To-Do-Elemente korrekt ausschließen.

Der Code für die sofortigen Updates ist auf GitHub verfügbar.

Tiefer graben

Wir können Cookies in jeder Server-Load-Funktion (oder Server-Aktion) setzen, nicht nur im Stamm-Layout. Wenn also bestimmte Daten nur unter einem einzelnen Layout oder sogar einer einzelnen Seite verwendet werden, könnten Sie diesen Cookie-Wert dort setzen. Darüber hinaus, wenn Sie den Trick, den ich gerade gezeigt habe, des manuellen Aktualisierens von Daten auf dem Bildschirm *nicht* durchführen, und stattdessen möchten, dass Ihr Lader nach einer Mutation neu ausgeführt wird, dann könnten Sie diesen Cookie-Wert immer direkt in dieser Load-Funktion setzen, ohne Prüfung gegen isDataRequest. Er wird anfänglich gesetzt, und dann wird jedes Mal, wenn Sie eine Server-Aktion ausführen, das Layout dieser Seite automatisch ungültig und ruft Ihren Lader erneut auf, wobei der Cache-Busting-String vor dem Aufruf Ihres universellen Laders zurückgesetzt wird.

Schreiben einer Reload-Funktion

Lassen Sie uns abschließen, indem wir ein letztes Feature erstellen: eine Reload-Schaltfläche. Geben wir den Benutzern eine Schaltfläche, die den Cache leert und dann die aktuelle Abfrage neu lädt.

Wir fügen eine sehr einfache Formularaktion hinzu.

async reloadTodos({ cookies }) {
  cookies.set('todos-cache', +new Date(), { path: '/', httpOnly: false });
},

In einem echten Projekt würden Sie wahrscheinlich nicht denselben Code kopieren/einfügen, um denselben Cookie auf dieselbe Weise an mehreren Stellen zu setzen, aber für diesen Beitrag werden wir auf Einfachheit und Lesbarkeit optimieren.

Erstellen wir nun ein Formular, das dorthin postet.

<form method="POST" action="?/reloadTodos" use:enhance>
  <button>Reload todos</button>
</form>

Das funktioniert!

Wir könnten dies als erledigt betrachten und weitermachen, aber lassen Sie uns diese Lösung etwas verbessern. Insbesondere geben wir dem Benutzer auf der Seite Feedback, dass der Reload stattfindet. Außerdem invalidiert SvelteKit-Aktionen standardmäßig *alles*. Jedes Layout, jede Seite usw. in der Hierarchie der aktuellen Seite würde neu geladen werden. Es kann Daten geben, die einmal im Stamm-Layout geladen werden und die wir nicht invalidieren oder neu laden müssen.

Konzentrieren wir uns also etwas mehr und laden nur unsere To-Dos neu, wenn wir diese Funktion aufrufen.

Zuerst übergeben wir eine Funktion zur Verbesserung.

<form method="POST" action="?/reloadTodos" use:enhance={reloadTodos}>

import { enhance } from "$app/forms";
import { invalidate } from "$app/navigation";

let reloading = false;
const reloadTodos = () => {
  reloading = true;

  return async () => {
    invalidate("reload:todos").then(() => {
      reloading = false;
    });
  };
};

Wir setzen eine neue Variable reloading auf true am *Anfang* dieser Aktion. Und dann, um das Standardverhalten des Invalidierens von allem zu überschreiben, geben wir eine async-Funktion zurück. Diese Funktion wird ausgeführt, wenn unsere Server-Aktion abgeschlossen ist (die nur einen neuen Cookie setzt).

Ohne diese zurückgegebene async-Funktion würde SvelteKit alles invalidieren. Da wir diese Funktion bereitstellen, wird nichts invalidiert, sodass es an uns liegt, ihm zu sagen, was neu geladen werden soll. Wir tun dies mit der Funktion invalidate. Wir rufen sie mit dem Wert reload:todos auf. Diese Funktion gibt ein Promise zurück, das aufgelöst wird, wenn die Invalidierung abgeschlossen ist, woraufhin wir reloading wieder auf false setzen.

Zuletzt müssen wir unseren Lader mit diesem neuen reload:todos-Invalidierungswert synchronisieren. Das tun wir in unserem Lader mit der Funktion depends.

export async function load({ fetch, url, setHeaders, depends }) {
    depends('reload:todos');

  // rest is the same

Und das war's. depends und invalidate sind unglaublich nützliche Funktionen. Was cool ist, ist, dass invalidate nicht nur beliebige Werte nimmt, die wir wie hier bereitstellen. Wir können auch eine URL angeben, die SvelteKit verfolgt und alle Lader invalidiert, die von dieser URL abhängen. Zu diesem Zweck, wenn Sie sich fragen, ob wir den Aufruf von depends überspringen und unseren Endpunkt /api/todos komplett invalidieren können, können Sie das tun, aber Sie müssen die *exakte* URL angeben, einschließlich des search-Terms (und unseres Cache-Wertes). Sie könnten also entweder die URL für die aktuelle Suche zusammenstellen oder auf den Pfadnamen wie folgt matchen:

invalidate(url => url.pathname == "/api/todos");

Persönlich finde ich die Lösung, die depends verwendet, expliziter und einfacher. Aber siehe die Dokumentation für weitere Informationen, natürlich, und entscheiden Sie selbst.

Wenn Sie den Reload-Button in Aktion sehen möchten, ist der Code dafür in diesem Branch des Repos.

Abschließende Gedanken

Dies war ein langer Beitrag, aber hoffentlich nicht überwältigend. Wir haben uns mit verschiedenen Möglichkeiten beschäftigt, wie wir Daten beim Verwenden von SvelteKit cachen können. Vieles davon war nur eine Frage der Verwendung von Webplattform-Primitiven, um den richtigen Cache und die richtigen Cookie-Werte hinzuzufügen. Kenntnisse darüber werden Ihnen bei der Webentwicklung im Allgemeinen dienen, auch außerhalb von SvelteKit.

Darüber hinaus ist dies etwas, das Sie absolut *nicht immer benötigen*. Man könnte argumentieren, dass Sie sich nur dann für solche fortgeschrittenen Funktionen entscheiden sollten, wenn Sie sie tatsächlich benötigen. Wenn Ihr Datenspeicher Daten schnell und effizient liefert und Sie keine Skalierungsprobleme haben, gibt es keinen Sinn, Ihren Anwendungscode mit unnötiger Komplexität zu belasten, indem Sie die hier besprochenen Dinge tun.

Schreiben Sie wie immer klaren, sauberen, einfachen Code und optimieren Sie bei Bedarf. Der Zweck dieses Beitrags war es, Ihnen diese Optimierungswerkzeuge für den Fall zu geben, dass Sie sie wirklich brauchen. Ich hoffe, es hat Ihnen gefallen!