Skip to content

Conversation

sebasti
Copy link
Member

@sebasti sebasti commented Oct 14, 2026 •

Issue

Closes #42

Endringer

  • listings tar nå imot limit (standard 24, maks 100) og offset (standard 0), og returnerer en ListingPage med items, totalCount og hasNextPage.
  • Ugyldig limit eller offset gir BAD_USER_INPUT. Valideringen ligger i backend/src/validation/paginationArgs.ts.
  • Annonsene sorteres på created_at DESC, id DESC. id som andre nøkkel gjør rekkefølgen stabil, slik at ingen annonser hoppes over eller vises to ganger mellom sidene.
  • createdAt er lagt til i Listing i GraphQL-skjemaet, som ISO 8601-tekst i UTC.
  • Ny migrasjon med indeksen listings_created_at_id_idx i samme rekkefølge som sorteringen. Første side går fra 2,5 ms til 0,01 ms med 10 000 annonser.
  • README, docs/datasett.md, docs/testing.md, docs/ki-bruk.md og curl-eksemplene i docs/vm-backend.md og backend/deploy/README.md er oppdatert. backend er lagt til som scope i prosjektstandarden.

Verdt å se på:

  • Brudd i API-et: listings returnerer en side, ikke en liste. Ingen klient bruker spørringen ennå.
  • Offset-paginering: sider langt bak blir tregere med mye data (siste side 3 ms ved 10 000 og 15 ms ved 50 000 annonser). Dette er dokumentert i docs/datasett.md, med cursor-paginering som mulig løsning senere.
  • VM-en: etter merge må npm run migrate kjøres på VM-en, og tjenesten må restartes. Dette berører [CONFIG] Last inn stort datasett i databasen på VM-en #41, som forventer to migrasjoner. Nå blir det tre.

Testing

Nye tester:

  • backend/src/graphql/listingsPagination.api.test.ts: første side, standard sidestørrelse, siste side, side utenfor treffmengden, totalCount, at hver annonse vises nøyaktig én gang på tvers av sider, rekkefølge ved like tidspunkt, format på createdAt og ugyldig limit og offset.
  • backend/src/validation/paginationArgs.test.ts: standardverdier og grenser, uten database.

Testen for like tidspunkt er kontrollert ved å endre sorteringen til feil rekkefølge med vilje. Den feilet da som den skulle.

Kjørt mot PostgreSQL 18 lokalt med 10 010 annonser. API-et er også prøvd med curl mot npm run start.

  • npm run typecheck (frontend og backend)
  • npm run lint
  • npm run format:check
  • npm test (frontend: 79 tester, backend: 41 tester mot testdatabase)
  • npm run build – frontend er ikke endret
  • Kontrollert i nettleser – gjelder ikke, bare backend er endret

Sjekkliste

  • README eller docs/ er oppdatert hvis det trengs
  • Eventuell KI-bruk er ført i docs/ki-bruk.md

Sebastian Ingebrigtsen and others added 6 commits October 14, 2026 21:31
Co-authored-by: tordtst <tordtst@ntnu.no>
Co-authored-by: birkjr <birkjr@ntnu.no>
Co-authored-by: andretg <andretg@ntnu.no>
Co-authored-by: tordtst <tordtst@ntnu.no>
Co-authored-by: birkjr <birkjr@ntnu.no>
Co-authored-by: andretg <andretg@ntnu.no>
@sebasti sebasti requested a review from a team as a code owner October 14, 2026 19:38
@sebasti sebasti merged commit ac0cc5b into dev Oct 14, 2026
@sebasti sebasti deleted the 42-feat-legg-til-paginering-i-listings-spørringen branch October 14, 2026 19:42
@tordtst
Copy link
Member

tordtst commented Oct 14, 2026

Bra jobba! Dette er en viktig endring. Etter hvert som antall annonser vokser, ville det blitt tregt og tungt å hente alt på én gang, så paginering er noe vi virkelig trenger.

Spesielt fint at id brukes som andre sorteringsnøkkel. Det gjør rekkefølgen stabil, så ingen annonser hoppes over eller dukker opp to ganger mellom sidene. Indeksen i samme rekkefølge som sorteringen er også et godt grep, og målingen fra 2,5 ms til 0,01 ms viser tydelig at det fungerer.

Valideringen med BAD_USER_INPUT og grensen på 100 gjør APIet tryggere, og det er ryddig at den ligger i en egen fil. Takk også for at README, dokumentasjonen og curl-eksemplene er oppdatert, det sparer oss for mye forvirring senere.

Godkjent herfra 👍

Sign in to join this conversation on GitHub.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants