Vue SSR liefert eine Locale
Das Dokument ist Englisch, Russisch oder Deutsch. Nicht alle drei. Sprachwechsel ist eine neue URL, kein zweites Wörterbuch im Heap.
Diese Site ist Vue SSR, keine SPA. Das erste HTML muss die Seite sein, die Crawler und Besucher beide sehen. Es muss auch zur Locale in der URL passen. Der alte Entry importierte bei jedem Render en, ru und de und wählte dann eine. Node behielt die anderen zwei im Isolat. Der serialisierte State wiederholte dieselben drei Wörterbücher, damit der Client die Sprache ohne Navigation wechseln konnte.
Niemand wechselte die Sprache ohne Navigation. Das extra JSON lag im Dokument und im Heap. Der vue-Container lag nach einem ruhigen Morgen bei etwa 700 MB.
Was der Entry jetzt lädt
Der SSR-Server lädt Messages nur für die Request-Locale. Der Client hydriert diese Tabelle. Ein Sprachwechsel trifft eine neue URL und ein neues Dokument. So arbeitet der Router bereits mit en, ru und de.
Formatierte Daten liegen im serialisierten State. Der Client rechnet sie nicht bei mount neu. Das entfernte eine Hydration-Warnung und einen Locale-Mismatch zugleich. Statische Bereiche, die i18n nie hören, bleiben nur serverseitig.
Was zu beobachten ist
Ein fehlender Message-Key fällt jetzt in einer Locale, nicht in drei. Seeds tragen weiter alle drei Sprachen, ein Formular, das nur die aktive Locale speichert, bleibt also ein Bug. Der vue-Prozess recycelt nach einer Speichergrenze, dieselbe Idee wie pm.max_requests bei PHP-FPM.
Der Heap eines warmen Workers lag bei etwa 180 MB. Das erste HTML verlor die ungenutzten Wörterbücher. Die Seite sieht gleich aus. Sie hört nur auf, zwei Sprachen mitzuschicken, die niemand verlangt hat.