Noroff API V2

[Fermain]

Goals

• [x] Upgrade to Prisma v5
• [x] Add Prisma seed script.
• [x] #114
• [x] Support text search
  • Encourage use of debounce in v2 docs
  • Perhaps use prisma.io/docs/full-text-search
• [x] Return pagination meta.
  • Use deptyped/prisma-extension-pagination
  • Schema:

    interface APIResponse {
    data: Data | Array<Data>
    meta: {
    isFirstPage: boolean
    isLastPage: boolean
    currentPage: number
    previousPage: number | null
    nextPage: number | null
    pageCount: number
    totalCount: number
    }
    }

• [x] Use API Keys for auth
  • Give back bearer token on login
  • Require bearer token to create API key
  • All protected routes require API key for auth
• [x] Add endpoint for creating an API key, e.g /api/v2/create-api-key
• [x] Testing with tap or jest
  • [x] Switch to executing a script for setting up and running tests rather than chaining commands in package.json.
  • Sometimes waiting for db to be ready leads to an issue as jest will attempt to run tests before the db is ready. We should implement wait-for-it.sh when switching to a bash script. Example
• [x] Add GitHub workflow for tests
• [x] Fix rate limiting
  • Static content is currently affecting the rate limit.
  • Serve static content via something like AWS S3 or Cloudflare R2
  • [x] Remove @fastify/static plugin and delete src/public dir.
  • Closes #88
• [x] Unify auth. Single auth endpoint for all of v2.
  • Closes #14
• [x] Generalize profile PUT endpoints rather than specifying /media in the URL. (/social/profiles/:name/media, and /auction/profiles/:name/media).
  • The Holidaze endpoint already does this: /holidaze/profiles/:name.
  • Allows us to make other fields editable in the future and not be stuck with /media in the URL.
• [x] Implement #61
• [x] Implement #13
• [x] Implement #17
  • Probably need to associate reactions with user for this to work as expected. Currently these are not related, so figuring out to add or remove a reaction isn't currently possible.
• [x] Implement #19
• [x] Implement #9
• [x] Implement #69
• [x] Implement #106
• [x] Fix TS build not including custom tsconfig paths.
  • Use tscpaths and update build script with tscpaths -p tsconfig.json -s ./ -o ./dist after tsc build step.
• [x] Return the booking user profile of each booking when requesting GET /holidaze/venues?_bookings=true and GET /holidaze/venues/:id?_bookings=true.
• [x] Return the owner user profile of each venue when requesting GET /holidaze/bookings?_venue=true and GET /holidaze/bookings/:id?_venue=true.
• [x] Return null rather than "Unknown" and 0 for Holidaze venue meta if left blank.
• [x] Use new Media model and schema (object with url/alt for images) for all basic endpoints.

Model progress

Each checkbox indicates all endpoints for that model has been migrated. I.e Books indicates GET /books ,GET /books/<id> and GET /books/random. This checklist is just to keep track of the general migration of endpoint from v1 to v2, and does not track additional features such as text search.

• [x] Books
• [x] Cat Facts
• [x] Jokes
• [x] NBA Teams
• [x] Old Games
• [x] Quotes
• [x] Online Shop
• [x] E-com - Rainy Days
• [x] E-com - Square Eyes
• [x] E-com - GameHub
• [x] Social - Auth (Will be unified)
• [x] Social - Posts
• [x] Social - Profiles
• [x] Auction House - Auth (Will be unified)
• [x] Auction House - Listings
• [x] Auction House - Profiles
• [x] Holidaze - Auth (Will be unified)
• [x] Holidaze - Profiles
• [x] Holidaze - Bookings
• [x] Holidaze - Listings

Stretch goals

• [ ] Add logging, e.g Sentry or Axiom
• [ ] Add monitoring, e.g Prometheus and Grafana. (Render has monitoring, but it's very limited)
• [ ] Create dashboard for users to login and create API keys using UI

[Fermain]

Will this unify auth?

[jaaneh]

Will this unify auth?

Good shout. Probably a good option to add as well. Only thing is that profiles usually have different properties, i.e holidaze has venueManager and auction house has credits. Probably can merge them all into a single profile and omit any that doesn't fit in the response.

[Fermain]

We could call it OneLogin

[Fermain]

I'm not sure what the best solution is, but things that come to mind:

• Kitchen sink (all props on all profiles)
• User only has essential common data and Profile is a related entity
• Way more detailed roles system