• docker staging step instead of only development and production

• multi stage docker build for lower image size

• usage of commitlint and aribnb's eslint config

• css obfuscation to reduce the size of style file shipped to the client

• file upload and drag & drop with image crop and preview

• infinite scroll with intersection observer instead of naive scroll listener

• loading skeleton instead of spinner

• full website accessability and usage of shadcn-ui

• SEO: metadata, robots.txt and dynamic sitemaps

• zod validation for

  • params
  • searchParams
  • localStorage
  • environment variables
  • user input
  • server payload

use crypto.randomUUID() instead of uuidv4() because it's x3-5 faster as it's part of node eco-system

Why split SongContext into ValueSongContext and DispatchSongContext?
because the buttons responsible for setting the song will re-render, even though they are not using its data

uses fetch() under the hood, leveraging the syntactic sugar like axios and the extended API of next.js

/artist/:id uses incremental static regeneration as it is not user speicifc data and not frequently changing, then revalidated each half hour for updates. SSR will be applied for new users

• consume server bandwidth
• overload the server with large number of users
• it would be better to take 2s of proccessing on the client, than taking the same 2s of sending high qulatiy image to the server to be procesed
• it's better to check only whether the image has the right size, format and dimentions on the server

if it's one node then no need to multilayer networks of swarm (leader / manager / worker)

# deploy with compose
docker compose -f docker-compose.prod.yml up -d db-prod && \
sleep 15s && \
dotenv -e .env.production.local -- npx prisma migrate reset dev && \
npm run docker:prod:build
docker compose -f docker-compose.prod.yml up -d

npm run docker:dev:up db-dev
npm run docker:dev:build
npm run docker:dev:up

npm run docker:dev:up
docker exec -it app-dev sh
docker logs -f app-dev
npm run prisma:studio:dev:env
npm run email:dev:env

any modification in node_modules should be applied in local machine for vscode intellicance, and in docker container for funtionality.
if it modifies package-lock.json like installation, then install on local first then on container so when your college pulls the repo and builds the docker image, it succeeds.

usually order wouldn't matter but when directory is created from the container it has root prevligae not user.

don't create migration files twice

# local machine
npm run prisma:migrate:dev:env

# docker container
npm run prisma:push:dev:env

-- to not pass the option to npm but to docker

# restart container
# e.g. for updating a schema
npm run docker:dev:up -- --force-recreate app-dev

• traefik config
• CI/CD for docker build and push
• download song
• payment