Übungsaufgaben zur Live-Aktualisierung mit Server-Sent Events: Mitfahrgesuche live anzeigen

Übungsaufgaben zur Live-Aktualisierung mit Server-Sent Events: Mitfahrgesuche live anzeigen

https://bildung.social/@oerinformatik/

https://oer-informatik.de/vue-change-request-live-uebungsaufgaben

Server-Sent Events, EventSource, SseEmitter, Polling, WebSocket, Verbindungsabbruch, Change Request, Regressionstest, Vue 3, Spring Boot, Übungsaufgaben, Prüfungsvorbereitung

tl/dr; (Bearbeitungszeit insgesamt 58 min, mehrere Aufgaben): Die Web-App des Mitfahrlabors aktualisiert die Fahrtenliste inzwischen live. In diesen Übungen baust Du dasselbe für die Mitfahrgesuche: zuerst in Vue mit einem kleinen Refactoring und einem Komponententest, dann im Backend mit SseEmitter und MockMvc. Danach findest Du anhand von Symptomen heraus, warum die Live-Aktualisierung nach Funklöchern, Server-Neustarts und hinter nginx versagt, machst sie robust und wägst für neue Wünsche der Schule Polling, Server-Sent Events, WebSocket und Push ab [AI-Assisted]. (Zuletzt geändert am 11.11.2026)

Dieser Artikel ist Teil einer Artikelreihe über die Web-App mit Vue 3 und TypeScript: Projektübersicht / XP-Projektstart / TypeScript für Java-Entwickler*innen / Komponenten testgetrieben / API-Client aus OpenAPI / Router und Continuous Integration / Formulare und Validierung / Refactoring mit Pinia / Anmeldung mit Keycloak / Fahrer-Sicht und Coding Standards / Build und Auslieferung / End-to-End-Tests mit Playwright / Change Request Live-Aktualisierung

Diese Übungsaufgaben gehören zum Artikel Change Request: Live-Aktualisierung mit Server-Sent Events. Alle Aufgaben spielen im Projektteam der Mitfahr-App Mitfahrlabor. Ausgangspunkt für die Aufgaben 2.1 und 3.1 ist das Projekt mitfahrlabor-web im Ordner src/12-vue-change-request-live des Repositorys dieser Reihe mit src/domain/liveaktualisierung.ts und src/composables/useLiveAktualisierung.ts; für Aufgabe 2.2 der Ordner backend-live/ darin mit AngebotEreignisse als Vorbild. Was für die Gesuche fehlt, steht vollständig in den Aufgaben.

Hinweise zur Bearbeitung: Als FIA, FIDP oder FIDV musst Du zur Teil-2-Prüfung Aufgaben auf Kernkompetenz-Ebene lösen können, das sind Aufgabe 2.1 und Aufgabe 2.2. Von FIA wird zusätzlich erwartet, dass ihnen Aufgaben auf Profilkompetenz-Ebene (Aufgabe 3.1 und Aufgabe 3.2) keine Probleme bereiten. Die Operatoren (entwickeln, ergänzen, erklären, analysieren, begründen, beurteilen, Stellung nehmen …) zeigen, wie ausführlich Du antworten sollst. Code in TypeScript prüfst Du mit npm test, npm run type-check und npm run lint, Java-Code mit den Tests des Backends (./gradlew test). Schreib Deine Lösung zuerst vollständig auf, bevor Du sie mit der Beispiellösung vergleichst.

Du möchtest eigene Aufgaben zum Üben von einem KI-Sprachmodell generieren lassen? Prompt ein-/ausblenden

Erstelle neue Übungsaufgaben zum Thema „Live-Aktualisierung mit Server-
Sent Events: Mitfahrgesuche live anzeigen“.

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-change-request-live
- https://oer-informatik.de/szenario-mitfahrlabor
- Stilbeispiel: https://oer-informatik.de/vue-change-request-live-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Server-Sent Events
- EventSource
- SseEmitter
- Polling
- WebSocket
- Verbindungsabbruch
- Change Request
- Regressionstest
- Vue 3
- Spring Boot

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.

Aufgabe 2.1: Live-Anzeige für Mitfahrgesuche (Kernkompetenz)

(ca. 15 min Bearbeitungszeit)

Marie Schulz (Pseudonym Ostwind) fährt jeden Morgen ab Herford. Sie möchte auf einer Seite die offenen Mitfahrgesuche sehen und neue sofort bemerken, um ihre freien Plätze anzubieten. Das Backend-Team kündigt dafür einen Ereignisstrom GET /v1/gesuche/ereignisse an: Er schickt Ereignisse mit dem Namen gesuch-geaendert und Daten wie {"gesuchId":5,"grund":"eingestellt"}; weitere Gründe sind vermittelt und zurueckgezogen.

Das Paar hat schon einen Typ und eine Komponente ohne Live-Aktualisierung gebaut. Lege src/domain/gesuche.ts an:

import type { Richtung } from './typen'

/** Ein Mitfahrgesuch, wie GET /v1/gesuche es liefert */
export interface Gesuch {
  id: number
  haltepunktId: number
  richtung: Richtung
  datum: string
  zeitVon: string
  zeitBis: string
  status: 'offen' | 'vermittelt' | 'zurueckgezogen'
}

export type GesuchQuelle = () => Promise<Gesuch[]>

und src/components/OffeneGesuche.vue:

<script setup lang="ts">
import { ref } from 'vue'
import type { Gesuch, GesuchQuelle } from '@/domain/gesuche'

const props = defineProps<{ quelle: GesuchQuelle }>()
const gesuche = ref<Gesuch[]>([])

async function laden() {
  gesuche.value = (await props.quelle()).filter((g) => g.status === 'offen')
}
laden()
</script>

<template>
  <h2>Offene Mitfahrgesuche</h2>
  <ul>
    <li v-for="g in gesuche" :key="g.id" :data-gesuch-id="g.id">
      {{ g.datum }}, {{ g.richtung }}, {{ g.zeitVon }} bis {{ g.zeitBis }} Uhr
    </li>
  </ul>
</template>

a) sseAenderungen() in src/domain/liveaktualisierung.ts kennt nur die Adresse und den Ereignisnamen der Angebote. Ergänze dort durch ein Refactoring eine allgemeine Funktion sseEreignisse<E>(adresse, ereignisname, Klasse), die eine AenderungsQuelle<E> liefert, und baue sseAenderungen() so um, dass es sie nutzt. Nenne, woran Du erkennst, dass das Refactoring das Verhalten nicht verändert hat. (4 Punkte)

/** Abonniert einen beliebigen Ereignisstrom und reicht die Daten jedes Ereignisses ereignisname weiter. */
export function sseEreignisse<E>(
  adresse: string,
  ereignisname: string,
  Klasse: EventSourceKlasse = globalThis.EventSource,
): AenderungsQuelle<E> {
  return (beiAenderung) => {
    if (!Klasse) return () => {} // ohne EventSource (z. B. jsdom): keine Live-Aktualisierung
    const verbindung = new Klasse(adresse)
    verbindung.addEventListener(ereignisname, (ereignis) => {
      beiAenderung(JSON.parse(ereignis.data) as E)
    })
    return () => verbindung.close()
  }
}

/** Abonniert GET /v1/angebote/ereignisse (unverändertes Verhalten, die Tests bleiben grün). */
export function sseAenderungen(
  adresse = `${import.meta.env.VITE_API_BASIS ?? '/v1'}/angebote/ereignisse`,
  Klasse: EventSourceKlasse = globalThis.EventSource,
): AenderungsQuelle {
  return sseEreignisse<Angebotsereignis>(adresse, ANGEBOT_GEAENDERT, Klasse)
}

b) Ergänze in src/domain/gesuche.ts einen Typ Gesuchsereignis und eine Funktion sseGesuchsaenderungen(adresse = '/v1/gesuche/ereignisse', Klasse?) und erweitere OffeneGesuche.vue um eine optionale Eigenschaft aenderungen, sodass die Liste bei jedem Ereignis neu lädt und die Verbindung geschlossen wird, wenn die Komponente verschwindet. (5 Punkte)

import { sseEreignisse, type AenderungsQuelle, type EventSourceKlasse } from './liveaktualisierung'

export interface Gesuchsereignis {
  gesuchId: number
  grund: 'eingestellt' | 'vermittelt' | 'zurueckgezogen'
}

export const GESUCH_GEAENDERT = 'gesuch-geaendert'

export function sseGesuchsaenderungen(
  adresse = '/v1/gesuche/ereignisse',
  Klasse?: EventSourceKlasse,
): AenderungsQuelle<Gesuchsereignis> {
  return sseEreignisse<Gesuchsereignis>(adresse, GESUCH_GEAENDERT, Klasse)
}

<script setup lang="ts">
import { ref } from 'vue'
import type { Gesuch, GesuchQuelle, Gesuchsereignis } from '@/domain/gesuche'
import type { AenderungsQuelle } from '@/domain/liveaktualisierung'
import { useLiveAktualisierung } from '@/composables/useLiveAktualisierung'

const props = defineProps<{ quelle: GesuchQuelle; aenderungen?: AenderungsQuelle<Gesuchsereignis> }>()
const gesuche = ref<Gesuch[]>([])

async function laden() {
  gesuche.value = (await props.quelle()).filter((g) => g.status === 'offen')
}
laden()
useLiveAktualisierung(props.aenderungen, laden)
</script>

c) Entwickle einen Komponententest mit Vitest und Vue Test Utils, der ohne Backend und ohne EventSource nachweist: Kommt ein Ereignis eingestellt, zeigt die Liste das neue Gesuch ohne Neuladen der Seite, und beim Entfernen der Komponente wird abgemeldet. (5 Punkte)

import { describe, it, expect } from 'vitest'
import { flushPromises, mount } from '@vue/test-utils'
import OffeneGesuche from '@/components/OffeneGesuche.vue'
import type { Gesuch, Gesuchsereignis } from '@/domain/gesuche'
import type { AenderungsQuelle } from '@/domain/liveaktualisierung'

const gesuch5: Gesuch = {
  id: 5,
  haltepunktId: 1,
  richtung: 'zur-schule',
  datum: '2026-11-19',
  zeitVon: '07:00',
  zeitBis: '07:30',
  status: 'offen',
}

describe('OffeneGesuche mit Live-Aktualisierung', () => {
  it('zeigt ein neu eingestelltes Gesuch ohne Neuladen und meldet sich beim Entfernen ab', async () => {
    let daten: Gesuch[] = []
    let melde!: (e: Gesuchsereignis) => void
    let abgemeldet = false
    const aenderungen: AenderungsQuelle<Gesuchsereignis> = (beiAenderung) => {
      melde = beiAenderung
      return () => (abgemeldet = true)
    }
    const wrapper = mount(OffeneGesuche, { props: { quelle: async () => [...daten], aenderungen } })
    await flushPromises()
    expect(wrapper.findAll('li')).toHaveLength(0)

    daten = [gesuch5]
    melde({ gesuchId: 5, grund: 'eingestellt' })
    await flushPromises()
    expect(wrapper.get('[data-gesuch-id="5"]').text()).toContain('07:00 bis 07:30 Uhr')

    wrapper.unmount()
    expect(abgemeldet).toBe(true)
  })
})

d) Jonas Wolff schlägt vor, das Gesuch gleich vollständig in das Ereignis zu schreiben, „dann spart die App eine Anfrage“. Begründe, warum das Team bei ID und Grund bleibt. (2 Punkte)

Aufgabe 2.2: Ereignisstrom für Gesuche im Backend (Kernkompetenz)

(ca. 15 min Bearbeitungszeit)

Das Backend-Team hat die Gesuche für den Übungsstrang auf IDs umgestellt, noch ohne Datenbank. Der Service sieht so aus (GesuchZeile ist der Record aus dem Übungsstrang des Backends mit ort, treffpunkt, richtung, datum, fruehestens, spaetestens und notiz):

@Service
public class GesuchService {

    private final Map<Long, GesuchZeile> offen = new ConcurrentHashMap<>();
    private final AtomicLong naechsteId = new AtomicLong(1);

    public long stelleEin(GesuchZeile gesuch) {
        long id = naechsteId.getAndIncrement();
        offen.put(id, gesuch);
        return id;
    }

    public boolean ziehZurueck(long id) {
        return offen.remove(id) != null;
    }

    public Map<Long, GesuchZeile> offeneGesuche() {
        return Map.copyOf(offen);
    }
}

a) Ergänze einen Record GesuchGeaendert(long gesuchId, String grund) und erweitere GesuchService so, dass stelleEin() und ein erfolgreiches ziehZurueck() dieses Ereignis über Spring veröffentlichen. (4 Punkte)

public record GesuchGeaendert(long gesuchId, String grund) {
}

@Service
public class GesuchService {

    private final Map<Long, GesuchZeile> offen = new ConcurrentHashMap<>();
    private final AtomicLong naechsteId = new AtomicLong(1);
    private final ApplicationEventPublisher ereignisse;

    public GesuchService(ApplicationEventPublisher ereignisse) {
        this.ereignisse = ereignisse;
    }

    public long stelleEin(GesuchZeile gesuch) {
        long id = naechsteId.getAndIncrement();
        offen.put(id, gesuch);
        ereignisse.publishEvent(new GesuchGeaendert(id, "eingestellt"));
        return id;
    }

    public boolean ziehZurueck(long id) {
        boolean gefunden = offen.remove(id) != null;
        if (gefunden) {
            ereignisse.publishEvent(new GesuchGeaendert(id, "zurueckgezogen"));
        }
        return gefunden;
    }

    public Map<Long, GesuchZeile> offeneGesuche() {
        return Map.copyOf(offen);
    }
}

b) Entwickle nach dem Vorbild von AngebotEreignisse eine Komponente GesuchEreignisse und einen Controller, der unter GET /v1/gesuche/ereignisse einen Ereignisstrom mit Ereignissen namens gesuch-geaendert und dem Record als JSON anbietet. Ein Lebenszeichen ist hier noch nicht verlangt. (6 Punkte)

@Component
public class GesuchEreignisse {

    private final List<SseEmitter> verbindungen = new CopyOnWriteArrayList<>();

    public SseEmitter verbinde() {
        SseEmitter emitter = new SseEmitter(30 * 60 * 1000L);
        verbindungen.add(emitter);
        emitter.onCompletion(() -> verbindungen.remove(emitter));
        emitter.onTimeout(emitter::complete);
        emitter.onError(fehler -> verbindungen.remove(emitter));
        return emitter;
    }

    @EventListener // noch keine Datenbank, also keine Transaktion, auf deren Commit man warten müsste
    public void beiAenderung(GesuchGeaendert aenderung) {
        for (SseEmitter emitter : verbindungen) {
            try {
                emitter.send(SseEmitter.event().name("gesuch-geaendert").data(aenderung, MediaType.APPLICATION_JSON));
            } catch (IOException | IllegalStateException abgebrochen) {
                verbindungen.remove(emitter);
            }
        }
    }
}

@RestController
public class GesuchEreignisController {

    private final GesuchEreignisse ereignisse;

    public GesuchEreignisController(GesuchEreignisse ereignisse) {
        this.ereignisse = ereignisse;
    }

    @GetMapping(path = "/v1/gesuche/ereignisse", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public SseEmitter abonniere(HttpServletResponse antwort) {
        antwort.setHeader("X-Accel-Buffering", "no");
        return ereignisse.verbinde();
    }
}

c) Entwickle einen Test mit MockMvc, der nachweist, dass nach stelleEin() im offenen Strom ein Ereignis gesuch-geaendert mit der richtigen ID und dem Grund eingestellt steht. (4 Punkte)

@SpringBootTest
@AutoConfigureMockMvc
class GesuchEreignisseTest {

    @Autowired MockMvc mvc;
    @Autowired GesuchService gesuche;

    @Test
    void meldetEinNeuesGesuchImEreignisstrom() throws Exception {
        MvcResult verbindung = mvc.perform(get("/v1/gesuche/ereignisse"))
                .andExpect(request().asyncStarted())
                .andReturn();

        long id = gesuche.stelleEin(new GesuchZeile("Gütersloh", "Hauptbahnhof, ZOB Steig 3", "zur Schule",
                LocalDate.of(2026, 11, 19), LocalTime.of(7, 0), LocalTime.of(7, 30), ""));

        String strom = verbindung.getResponse().getContentAsString();
        assertThat(strom).contains("event:gesuch-geaendert\n")
                .contains("data:{\"gesuchId\":" + id + ",\"grund\":\"eingestellt\"}\n\n");
    }
}

d) Begründe, warum GesuchEreignisse hier @EventListener nutzen darf, während AngebotEreignisse @TransactionalEventListener nutzt, und was sich ändert, sobald die Gesuche in der Datenbank liegen. (2 Punkte)

Aufgabe 3.1: Live-Aktualisierung, die manchmal versagt (Profilkompetenz)

(ca. 15 min Bearbeitungszeit)

Nach zwei Wochen mit WEB-14 kommen drei Meldungen bei Thomas Becker an. Der Code ist der aus Stand 12 (sseAenderungen() und useLiveAktualisierung() wie im Artikel); er ist in diesen Fällen absichtlich nicht robust.

• Meldung A: Aylin Kaya hat die Suche im Zug offen. Nach einem Funkloch von etwa zwei Minuten zeigt die Liste eine Fahrt mit „1 Platz frei“, die längst voll ist. Erst als später eine andere Fahrt bestätigt wird, stimmt die Liste wieder.
• Meldung B: Auf dem Rechner im Sekretariat steht die Suche den ganzen Tag offen. Seit dem nächtlichen Neustart des Backends, bei dem nginx etwa 20 Sekunden lang mit 502 antwortet, aktualisiert sie sich nicht mehr, bis jemand die Seite neu lädt.
• Meldung C: Jonas hat die Gesuche aus Aufgabe 2.2 auf dem Testserver ausprobiert, dessen nginx nur den allgemeinen Block für /v1/ hat, und in GesuchEreignisController den Header X-Accel-Buffering weggelassen. Im Entwicklungsserver kommen die Ereignisse sofort; auf dem Testserver kommen sie gesammelt, und im Netzwerk-Tab des Browsers erscheint ungefähr jede Minute eine neue Anfrage an /v1/gesuche/ereignisse.

a) Analysiere die drei Meldungen: Erkläre jeweils die Ursache und gib an, in welchem Zustand (readyState) sich die EventSource befindet. (6 Punkte)

b) Entwickle eine Funktion sseAenderungenRobust(adresse, Klasse, ersteWartezeitMs = 2000, laengsteWartezeitMs = 60000) in src/domain/robusteaktualisierung.ts, die wie sseAenderungen() eine AenderungsQuelle liefert, aber Meldung A und B behebt: Nach einer Wiederverbindung meldet sie einmal eine Änderung, damit die Suche neu lädt; eine aufgegebene Verbindung baut sie nach einer Wartezeit neu auf, die sich bei jedem Fehlschlag verdoppelt (höchstens laengsteWartezeitMs) und nach einer erfolgreichen Verbindung zurückgesetzt wird. Nach dem Abmelden darf sie sich nicht mehr verbinden. Beschreibe, wie Du die Funktion ohne Browser testest. (7 Punkte)

import type { Angebotsereignis } from './typen'
import { ANGEBOT_GEAENDERT, type AenderungsQuelle } from './liveaktualisierung'

/** Was die robuste Fassung zusätzlich von EventSource braucht */
export interface RobusteVerbindung {
  readonly readyState: number
  addEventListener(typ: string, lauscher: (ereignis: MessageEvent<string>) => void): void
  close(): void
}
export type RobusteKlasse = new (adresse: string) => RobusteVerbindung

const GESCHLOSSEN = 2 // EventSource.CLOSED

export function sseAenderungenRobust(
  adresse = '/v1/angebote/ereignisse',
  Klasse: RobusteKlasse = globalThis.EventSource,
  ersteWartezeitMs = 2000,
  laengsteWartezeitMs = 60000,
): AenderungsQuelle {
  return (beiAenderung) => {
    if (!Klasse) return () => {}
    let verbindung: RobusteVerbindung | undefined
    let unterbrochen = false
    let wartezeit = ersteWartezeitMs
    let zeitgeber: ReturnType<typeof setTimeout> | undefined
    let beendet = false

    // Ereignis ohne bestimmte ID: „irgendetwas kann sich geändert haben“ – die Suche lädt einfach neu
    const allesNeu: Angebotsereignis = { angebotId: 0, grund: 'geaendert' }

    function verbinde() {
      verbindung = new Klasse(adresse)
      verbindung.addEventListener('open', () => {
        wartezeit = ersteWartezeitMs
        if (unterbrochen) beiAenderung(allesNeu) // verpasste Ereignisse nachholen
        unterbrochen = false
      })
      verbindung.addEventListener('error', () => {
        unterbrochen = true
        if (verbindung?.readyState === GESCHLOSSEN && !beendet) {
          // EventSource gibt bei HTTP-Fehlern und falschem Content-Type auf: selbst neu verbinden
          zeitgeber = setTimeout(verbinde, wartezeit)
          wartezeit = Math.min(wartezeit * 2, laengsteWartezeitMs)
        }
      })
      verbindung.addEventListener(ANGEBOT_GEAENDERT, (e) => beiAenderung(JSON.parse(e.data) as Angebotsereignis))
    }

    verbinde()
    return () => {
      beendet = true
      clearTimeout(zeitgeber)
      verbindung?.close()
    }
  }
}

c) Gib an, wie Jonas Meldung C behebt, und nenne eine Möglichkeit für den Fall, dass er nginx nicht selbst ändern darf. (3 Punkte)

location = /v1/gesuche/ereignisse {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    proxy_read_timeout 1h;
}

Aufgabe 3.2: Polling, Server-Sent Events oder WebSocket? (Profilkompetenz)

(ca. 13 min Bearbeitungszeit)

Nach der erfolgreichen Abnahme von WEB-14 sammelt Thomas Becker weitere Wünsche der Schule:

• W1: Die Flurmonitore sollen wie bisher offene Fahrten zeigen; das Abnahmekriterium lässt 60 Sekunden Verzögerung zu.
• W2: Wer fährt, und wer mitfährt, sollen sich vor der Fahrt kurze Nachrichten schreiben können („Ich stehe am Steig 3“).
• W3: Marie möchte auf der Detailseite ihrer Fahrt neue Anfragen sofort sehen, mit dem Pseudonym der anfragenden Person.
• W4: Ben möchte auf dem Telefon benachrichtigt werden, wenn jemand bei seiner Fahrt anfragt, auch wenn die App gerade nicht geöffnet ist.

a) Wähle für jeden Wunsch ein Verfahren (Polling, Server-Sent Events, WebSocket oder ein anderes) und begründe Deine Wahl. (8 Punkte)

b) Jonas Wolff schlägt vor: „Stellen wir doch alles auf WebSocket um, dann haben wir nur noch eine Technik.“ Nimm Stellung. (4 Punkte)

c) Thomas möchte W3 mitten in Iteration 7 noch unterbringen. Beschreibe, wie das XP-Team damit umgeht. (2 Punkte)

Links und weitere Informationen

• Change Request: Live-Aktualisierung mit Server-Sent Events: der Artikel zu diesen Übungen

• MDN: Using server-sent events und MDN: EventSource readyState

• Spring Framework: Asynchronous Requests (SSE)

• MDN: Push API und MDN: WebSocket API

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Übungsaufgaben zur Live-Aktualisierung mit Server-Sent Events: Mitfahrgesuche live anzeigen” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/vue-change-request-live-uebungsaufgaben veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/programmierung/vue. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 11.11.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]