Übungsaufgaben zu Build und Auslieferung einer Vue-App: Mitfahrgesuche im Intranet

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Build und Auslieferung einer
Vue-App: Mitfahrgesuche im Intranet“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/vue-build-auslieferung
- https://oer-informatik.de/szenario-mitfahrlabor
- Stilbeispiel: https://oer-informatik.de/vue-build-auslieferung-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Vue 3
- Vite
- Produktions-Build
- Umgebungsvariablen
- base
- History-Mode
- Deep Link
- nginx
- try_files
- Caching

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Beim ersten Aufruf von /: index.html, dann das Haupt-Bundle assets/index-CE0DqqM_.js und das Stylesheet assets/index-CqLr8KVv.css (dazu favicon.ico aus public/, das in der Liste nicht erscheint) (1 Punkt).

Beim Klick auf „Details“: assets/AngebotSeite-krQG8s6B.js und assets/problem-odPE36Kg.js (1 Punkt); danach die Daten über /v1/angebote/….

problem-…js ist ein gemeinsamer Chunk: Zwei nachgeladene Seiten brauchen denselben Code. Steckte er in beiden, würde er doppelt geladen; stünde er im Haupt-Bundle, müsste ihn jede Person schon beim Start laden, auch wenn sie nie eine Detailseite öffnet (1 Punkt).

Die Spalte zeigt die ungefähre Größe, wenn die Datei mit gzip komprimiert übertragen wird; auf der Platte liegt die Datei unkomprimiert mit der ersten Zahl (1 Punkt). Für die Ladezeit zählt die gzip-Zahl, aber nur, wenn der Webserver komprimiert überträgt (in nginx gzip on mit passenden gzip_types); sonst wird die volle Größe übertragen (1 Punkt).

Sicher neu: AngebotSeite-….js, weil sich sein Inhalt und damit der Hash ändert (1 Punkt), und das Haupt-Bundle index-….js, weil es die Namen der nachzuladenden Chunks enthält (1 Punkt). index.html behält den Namen, verweist aber auf das neue Haupt-Bundle.

Sicher gleich: index-CqLr8KVv.css und problem-odPE36Kg.js, ihr Inhalt ist unverändert (1 Punkt).

Hinweis: In Stand 10 ändern sich zusätzlich AngebotNeuSeite-…, AnmeldungRueckkehr-… und NichtGefundenSeite-…, denn sie importieren aus dem Haupt-Bundle, dessen Name sich geändert hat. Wer das vorhersagt, hat den Mechanismus verstanden; für die Punkte genügen die sicheren Fälle.

Je richtig entschiedener und begründeter Aussage ½ Punkt:

1. Falsch: dist/ enthält nur statische Dateien, jeder Webserver kann sie ausliefern; der Code läuft im Browser.
2. Falsch: index.html behält bei jedem Release ihren Namen; mit langer Cache-Dauer sähen Nutzende weiter die alte Version. Sie bekommt no-cache.
3. Richtig: Vite schreibt den Wert beim Bauen als Text ins JavaScript, das jede Person herunterlädt.
4. Falsch: Die Werte werden beim Bauen festgeschrieben; ohne neuen Build ändert sich nichts.

Neue Datei .env.development (1 Punkt):

VITE_GESUCHE_ANZEIGEN=true

Ergänzung in .env.production (1 Punkt):

# Ansicht der Mitfahrgesuche: aus, bis das Backend /v1/gesuche anbietet
VITE_GESUCHE_ANZEIGEN=false

In env.d.ts im Interface ImportMetaEnv (1 Punkt), optional und als Text, weil .env-Dateien nur Text kennen:

  /** Ansicht der Mitfahrgesuche: 'true' = an, sonst aus */
  readonly VITE_GESUCHE_ANZEIGEN?: string

Die Variable muss mit VITE_ beginnen, sonst nimmt Vite sie nicht in import.meta.env auf. Ein Eintrag in .env statt .env.development wäre auch möglich, dann muss .env.production ihn überschreiben.

/** Umgebungsvariablen, die die Schalter lesen (im Test als einfaches Objekt übergeben) */
type Schalter = Pick<ImportMetaEnv, 'VITE_GESUCHE_ANZEIGEN'>

/** Gesuche anzeigen? Nur der Text 'true' schaltet ein; fehlt die Variable, bleibt die Ansicht aus. */
export function gesucheAktiv(env: Schalter = import.meta.env): boolean {
  return env.VITE_GESUCHE_ANZEIGEN === 'true'
}

Punkte: Vergleich mit dem Text 'true' statt Umwandlung mit Boolean(...) (der Text 'false' wäre sonst true) (1 Punkt), fehlende Variable ergibt false (1 Punkt), Parameter mit Voreinstellung import.meta.env und passendem Typ, damit Tests ein eigenes Objekt übergeben können (1 Punkt).

import { gesucheAktiv } from '@/domain/schalter'

/** Route der Gesuche nur, wenn der Schalter an ist */
export function gesucheRouten(aktiv: boolean = gesucheAktiv()): RouteRecordRaw[] {
  return aktiv ? [{ path: '/gesuche', name: 'gesuche', component: () => import('@/views/GesucheSeite.vue') }] : []
}

In routes vor der Route „nicht gefunden“ (die Reihenfolge ist für den Router egal, aber so bleibt die Tabelle lesbar):

  ...gesucheRouten(),
  { path: '/:pfad(.*)*', name: 'nicht-gefunden', component: () => import('@/views/NichtGefundenSeite.vue') },

Funktion mit beiden Fällen (1 Punkt), Einbau per Spread in die Tabelle (1 Punkt). Ist der Schalter aus, landet /gesuche auf der Seite „nicht gefunden“.

import { afterEach, describe, expect, it, vi } from 'vitest'
import { gesucheAktiv } from '@/domain/schalter'
import { gesucheRouten } from '@/router'

describe('Schalter für die Gesuche', () => {
  afterEach(() => vi.unstubAllEnvs())

  it('ist nur mit dem Text true an', () => {
    expect(gesucheAktiv({ VITE_GESUCHE_ANZEIGEN: 'true' })).toBe(true)
    expect(gesucheAktiv({ VITE_GESUCHE_ANZEIGEN: 'false' })).toBe(false)
    expect(gesucheAktiv({ VITE_GESUCHE_ANZEIGEN: 'ja' })).toBe(false)
    expect(gesucheAktiv({})).toBe(false)
  })

  it('liest ohne Argument import.meta.env', () => {
    vi.stubEnv('VITE_GESUCHE_ANZEIGEN', 'true')
    expect(gesucheAktiv()).toBe(true)
    vi.stubEnv('VITE_GESUCHE_ANZEIGEN', 'false')
    expect(gesucheAktiv()).toBe(false)
  })

  it('meldet die Route /gesuche nur bei eingeschaltetem Schalter an', () => {
    expect(gesucheRouten(true).map((r) => r.path)).toEqual(['/gesuche'])
    expect(gesucheRouten(false)).toEqual([])
  })
})

Je Test 1 Punkt. vi.unstubAllEnvs() stellt nach jedem Test die ursprünglichen Werte wieder her, damit andere Tests nicht beeinflusst werden. Vitest läuft im Modus test; .env.development und .env.production gelten dort nicht, deshalb setzt der Test die Werte selbst.

Der Schalter blendet nur die Route aus: Wer /gesuche aufruft, landet auf „nicht gefunden“ (1 Punkt). Der Code der Seite wird trotzdem gebaut und ausgeliefert (im Build steht assets/GesucheSeite-….js), und der Wert false steht lesbar im Haupt-Bundle; wer die Dateien ansieht, findet die Seite. Ein Schalter in der Oberfläche ist eine Hilfe für Releases, kein Schutz. Daten schützt nur das Backend, und das bietet die Gesuche ohnehin noch nicht an (1 Punkt).

npm run build -- --base=/mitfahrlabor/

Alternativ base: '/mitfahrlabor/' in vite.config.ts, dann gilt es aber auch für den Teamserver (1 Punkt).

In dist/index.html stehen die Verweise jetzt mit Unterordner, etwa src="/mitfahrlabor/assets/index-….js" und href="/mitfahrlabor/favicon.ico"; auch die Adressen der nachgeladenen Chunks beginnen mit /mitfahrlabor/ (1 Punkt). import.meta.env.BASE_URL ist /mitfahrlabor/; createWebHistory(import.meta.env.BASE_URL) legt die Routen darunter, /angebote/1 heißt also /mitfahrlabor/angebote/1. Seit Stand 10 enthält auch die Rückkehr-Adresse der Anmeldung den Unterordner (1 Punkt).

    # API: wie auf dem Teamserver an das Backend weiterreichen
    location /v1/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # Assets der App: ein Jahr Cache, fehlende Dateien ehrlich 404
    location /mitfahrlabor/assets/ {
        try_files $uri =404;
        add_header Cache-Control "public, max-age=31536000, immutable";
    }

    # App: Dateien oder die App-Hülle des Unterordners
    location /mitfahrlabor/ {
        try_files $uri $uri/ /mitfahrlabor/index.html;
        add_header Cache-Control "no-cache";
    }

Punkte: Proxy für /v1/ (1 Punkt); Assets mit =404 und immutable (2 Punkte); App-Block mit Fallback auf /mitfahrlabor/index.html, nicht /index.html (das wäre die Startseite des Intranets) (2 Punkte); no-cache für die Hülle, location / des Intranets unverändert (1 Punkt).

Mit root /srv/intranet sucht nginx /mitfahrlabor/assets/x.js unter /srv/intranet/mitfahrlabor/assets/x.js, ein alias ist nicht nötig. Wer /mitfahrlabor ohne Schrägstrich aufruft, bekommt von nginx eine Umleitung auf /mitfahrlabor/, weil es den Ordner gibt. Die Konfiguration ist mit nginx 1.24 geprüft; Deep Links wie /mitfahrlabor/angebote/1 liefern 200 mit der App-Hülle.

Redirect URI https://intranet.dbh.example/mitfahrlabor/anmeldung/rueckkehr, Web Origin https://intranet.dbh.example und als Adresse nach dem Abmelden https://intranet.dbh.example/mitfahrlabor/ (1 Punkt). Ohne Redirect URI zeigt Keycloak statt der Anmeldeseite die Fehlermeldung Invalid parameter: redirect_uri; ohne Web Origin scheitert das Abholen des Tokens an der CORS-Prüfung des Browsers (1 Punkt).

Ohne zweiten Parameter prüft das Skript die API unter https://intranet.dbh.example/mitfahrlabor/v1/haltepunkte. Diesen Pfad fängt der Block location /mitfahrlabor/ mit dem Fallback ab: Status 200, aber mit der App-Hülle. „API über den Proxy erreichbar“ meldet deshalb ok, „API liefert JSON, nicht die App-Hülle“ scheitert mit erhalten '<' (2 Punkte). Die API liegt am Wurzelpfad des Servers, nicht im Unterordner. Richtiger Aufruf (1 Punkt):

bash nginx/pruefe-auslieferung.sh https://intranet.dbh.example/mitfahrlabor https://intranet.dbh.example

Je Symptom 1 Punkt für die Ursache, 1 Punkt für die Erläuterung:

1. Gebaut ohne base. index.html verweist mit /assets/index-….js auf den Wurzelpfad des Servers. Dort gibt es keinen Ordner assets, nginx antwortet mit 404, die App startet nicht, und <div id="app"> bleibt leer.
2. Kein Fallback. try_files $uri $uri/ =404 liefert nur vorhandene Dateien. Beim Klicken ändert der Router die Adresse ohne den Server; beim Neu laden fragt der Browser nach /mitfahrlabor/angebote/4, eine solche Datei gibt es nicht.
3. index.html mit langer Cache-Dauer. Die Regel max-age=31536000, immutable gilt für den ganzen Block, also auch für index.html. Der Browser nimmt die gespeicherte alte Hülle, ohne nachzufragen, und lädt damit die alten Bundles (die noch auf dem Server liegen). Erst Strg+F5 erzwingt eine neue Anfrage.
4. Redirect URI fehlt im Realm. Die App schickt https://intranet.dbh.example/mitfahrlabor/anmeldung/rueckkehr als Rückkehr-Adresse; Keycloak leitet nur an eingetragene Adressen zurück und bricht sonst ab. (Mit einem Stand vor 10 hätte die App sogar …/anmeldung/rueckkehr ohne Unterordner geschickt; dann hätte auch der Eintrag mit Unterordner nicht geholfen.)

Build mit Unterordner (1 Punkt):

npm run build -- --base=/mitfahrlabor/

Konfiguration: Assets getrennt mit langer Cache-Dauer (2 Punkte), App mit Fallback auf die eigene Hülle und no-cache (2 Punkte):

    location /mitfahrlabor/assets/ {
        try_files $uri =404;
        add_header Cache-Control "public, max-age=31536000, immutable";
    }

    location /mitfahrlabor/ {
        try_files $uri $uri/ /mitfahrlabor/index.html;
        add_header Cache-Control "no-cache";
    }

Dazu kommt der Eintrag der Redirect URI im Realm (siehe Aufgabe 2.2 c). Wer Symptom 3 schon hatte: Die alte index.html liegt bei den Betroffenen noch bis zu einem Jahr im Cache; einmal Strg+F5 oder das Leeren des Caches ist nötig. Eine solche Panne lässt sich nachträglich nicht vom Server aus beheben.

Der Vorschlag beseitigt die 404, liefert aber die falsche Seite: /index.html ist hier die Startseite des Intranets unter /srv/intranet/index.html, nicht die App-Hülle. Aylin sähe beim Neu laden das Intranet statt der Fahrt (1 Punkt). Im Artikel liegt die App am Wurzelpfad ihrer eigenen Domain, deshalb passt dort /index.html. Im Unterordner muss der Fallback /mitfahrlabor/index.html heißen; der Rauchtest mit der Prüfung „Deep Link liefert die App-Hülle“ hätte den Fehler gefunden (1 Punkt).