BE: Personen-Endpunkte optimieren (?include=group, /me/summary, /me konsolidieren) #171

New issue

Closed

opened 2026-07-02 20:06:36 +02:00 by niboer · 0 comments

niboer commented

2026-07-02 20:06:36 +02:00

Owner

Beschreibung

Drei zusammengehoerige Optimierungen an den Personen-Endpunkten zur Reduktion von Frontend-API-Calls:

?include=group an GET /api/v1/persons und GET /api/v1/persons/{person_id}
Neuer Endpunkt GET /api/v1/persons/me/summary (Dashboard-Bundle)
GET /api/v1/persons/me konsolidieren (aktuell 2 DB-Queries → 1)

Motivation / Anwendungsfall

?include=group: Es gibt keinen Reverse-Lookup Person→Gruppe via API. Das Frontend muss alle Groups durchprobieren, um die Gruppe einer Person zu finden. Da GroupMember.personId unique ist (1 Person = max 1 Gruppe), kann das Backend die Info inline liefern.

Dashboard-Summary: Die Startseite macht 5+ separate API-Calls (person, invitations, events, groups, consent). Ein einziger /me/summary-Endpunkt reduziert das auf 1 Call.

/me konsolidieren: Aktuell werden person + consent in zwei separaten Queries geladen. Ein include: { contactData, consentsGiven: { take:1 } } reicht.

Vorgeschlagene Umsetzung

OpenAPI:

# 1. ?include=group an GET /persons + /persons/{person_id}
PersonWithGroup:
  allOf:
    - $ref: '#/components/schemas/Person'
    - type: object
      properties:
        group:
          nullable: true
          type: object
          properties:
            groupId: { type: string, format: uuid }
            name: { type: string }

# 2. Neuer Summary-Endpunkt
/persons/me/summary:
  get:
    operationId: getMeSummary
    summary: Gebuendelte Dashboard-Daten (Person, Gruppe, Consent, Einladungen, Events)
    responses:
      '200':
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/MeSummary'

MeSummary:
  type: object
  properties:
    person:      { $ref: '#/components/schemas/Person' }
    group:       { $ref: '#/components/schemas/Group', nullable: true }
    consent:     { type: boolean }
    invitations: { type: array, items: { $ref: '#/components/schemas/Invitation' } }
    events:      { type: array, items: { $ref: '#/components/schemas/Event' } }

Backend:

persons.ts: Bedingtes include in Prisma-Query analog Gruppen-Endpunkten
GET /me/summary: Neue Route, die eine einzige Prisma-Query mit allen Includes und einen parallelisierbaren Promise.all-Block fuer Invitations nutzt

Labels

component/backend, prio/medium, type/feature

Meilenstein

MS-REST (#32)

### Beschreibung Drei zusammengehoerige Optimierungen an den Personen-Endpunkten zur Reduktion von Frontend-API-Calls: 1. **`?include=group`** an `GET /api/v1/persons` und `GET /api/v1/persons/{person_id}` 2. **Neuer Endpunkt `GET /api/v1/persons/me/summary`** (Dashboard-Bundle) 3. **`GET /api/v1/persons/me` konsolidieren** (aktuell 2 DB-Queries → 1) ### Motivation / Anwendungsfall **?include=group:** Es gibt keinen Reverse-Lookup Person→Gruppe via API. Das Frontend muss alle Groups durchprobieren, um die Gruppe einer Person zu finden. Da `GroupMember.personId` unique ist (1 Person = max 1 Gruppe), kann das Backend die Info inline liefern. **Dashboard-Summary:** Die Startseite macht 5+ separate API-Calls (person, invitations, events, groups, consent). Ein einziger `/me/summary`-Endpunkt reduziert das auf 1 Call. **/me konsolidieren:** Aktuell werden person + consent in zwei separaten Queries geladen. Ein `include: { contactData, consentsGiven: { take:1 } }` reicht. ### Vorgeschlagene Umsetzung **OpenAPI:** ```yaml # 1. ?include=group an GET /persons + /persons/{person_id} PersonWithGroup: allOf: - $ref: '#/components/schemas/Person' - type: object properties: group: nullable: true type: object properties: groupId: { type: string, format: uuid } name: { type: string } # 2. Neuer Summary-Endpunkt /persons/me/summary: get: operationId: getMeSummary summary: Gebuendelte Dashboard-Daten (Person, Gruppe, Consent, Einladungen, Events) responses: '200': content: application/json: schema: $ref: '#/components/schemas/MeSummary' MeSummary: type: object properties: person: { $ref: '#/components/schemas/Person' } group: { $ref: '#/components/schemas/Group', nullable: true } consent: { type: boolean } invitations: { type: array, items: { $ref: '#/components/schemas/Invitation' } } events: { type: array, items: { $ref: '#/components/schemas/Event' } } ``` **Backend:** - `persons.ts`: Bedingtes `include` in Prisma-Query analog Gruppen-Endpunkten - `GET /me/summary`: Neue Route, die eine einzige Prisma-Query mit allen Includes und einen parallelisierbaren `Promise.all`-Block fuer Invitations nutzt ### Labels component/backend, prio/medium, type/feature ### Meilenstein MS-REST (#32)

niboer added this to the MS-REST: Restliche Aufgaben milestone

2026-07-02 20:06:36 +02:00

niboer added the

prio/medium

type/feature

component/backend

labels

2026-07-02 20:06:36 +02:00

niboer referenced this issue

2026-07-02 20:13:03 +02:00

FE: Consent-Dialog und Person-Detail von Waterfall-Requests befreien #172

niboer referenced this issue from a commit