BE: Gruppen-Endpunkte um ?include=members erweitern #169

New issue

Closed

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

niboer commented

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

Owner

Beschreibung

GET /api/v1/groups und GET /api/v1/groups/{group_id} um einen ?include=members-Query-Parameter erweitern, der Gruppen-Mitglieder inkl. Personendaten (firstName, lastName) direkt im Response einbettet.

Motivation / Anwendungsfall

Das Frontend macht aktuell fuer jede Gruppen-Ansicht 1 + N API-Calls (alle Gruppen, dann pro Gruppe /members). Das skaliert schlecht mit wachsender Gruppenanzahl. Ein ?include=members eliminiert das N+1-Problem vollstaendig.

Vorgeschlagene Umsetzung

OpenAPI (openapi.yaml):

Neuer Query-Parameter include (string, enum: members) an GET /api/v1/groups und GET /api/v1/groups/{group_id}
Neues Schema GroupWithMembers (allOf: Group + members-Array)
GroupMemberWithPerson-Schema mit personId, firstName, lastName, joinedAt, invitedBy, approvedBy

Backend (Fastify-Route groups.ts):

querystring-Schema um include ergaenzen
Bedingtes include: { members: { include: { person: { select: { personId, firstName, lastName } } } } } in der Prisma-Query
400 bei invaliden Werten (analog bestehendem ?fields=-Pattern)

Response-Beispiel:

{
  "groupId": "uuid",
  "name": "Familie Mueller",
  "members": [
    {
      "personId": "uuid",
      "firstName": "Hans",
      "lastName": "Mueller",
      "joinedAt": "2025-01-15T10:00:00Z",
      "invitedBy": "uuid",
      "approvedBy": "uuid"
    }
  ]
}

Alternativen

Eigener Endpunkt GET /api/v1/groups/members-summary — weniger flexibel
Response immer mit Members — mehr Bandbreite, wenn Members nicht benoetigt

Labels

component/backend, prio/high, type/feature

Meilenstein

MS-REST (#32)

### Beschreibung `GET /api/v1/groups` und `GET /api/v1/groups/{group_id}` um einen `?include=members`-Query-Parameter erweitern, der Gruppen-Mitglieder inkl. Personendaten (firstName, lastName) direkt im Response einbettet. ### Motivation / Anwendungsfall Das Frontend macht aktuell fuer jede Gruppen-Ansicht 1 + N API-Calls (alle Gruppen, dann pro Gruppe `/members`). Das skaliert schlecht mit wachsender Gruppenanzahl. Ein `?include=members` eliminiert das N+1-Problem vollstaendig. ### Vorgeschlagene Umsetzung **OpenAPI (openapi.yaml):** - Neuer Query-Parameter `include` (string, enum: `members`) an `GET /api/v1/groups` und `GET /api/v1/groups/{group_id}` - Neues Schema `GroupWithMembers` (allOf: Group + members-Array) - `GroupMemberWithPerson`-Schema mit `personId`, `firstName`, `lastName`, `joinedAt`, `invitedBy`, `approvedBy` **Backend (Fastify-Route groups.ts):** - `querystring`-Schema um `include` ergaenzen - Bedingtes `include: { members: { include: { person: { select: { personId, firstName, lastName } } } } }` in der Prisma-Query - 400 bei invaliden Werten (analog bestehendem `?fields=`-Pattern) **Response-Beispiel:** ```json { "groupId": "uuid", "name": "Familie Mueller", "members": [ { "personId": "uuid", "firstName": "Hans", "lastName": "Mueller", "joinedAt": "2025-01-15T10:00:00Z", "invitedBy": "uuid", "approvedBy": "uuid" } ] } ``` ### Alternativen - Eigener Endpunkt `GET /api/v1/groups/members-summary` — weniger flexibel - Response immer mit Members — mehr Bandbreite, wenn Members nicht benoetigt ### Labels component/backend, prio/high, type/feature ### Meilenstein MS-REST (#32)

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

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

niboer added the

prio/high

type/feature

component/backend

labels

2026-07-02 20:06:24 +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