BISO Docs

Quality and Operations

Security, performance, scalability, and build pipeline for BISO Sites.

Quality and Operations

Cross-cutting concerns: how we build and ship, and how the system is expected to behave under load. For stack choices (Turborepo, Bun, Appwrite, and so on), see Design decisions.

Build and deploy pipeline

Characteristics:

  • Incremental builds — Rebuild only what changed
  • Caching — Local and (when configured) remote cache
  • Parallelism — Multiple apps and packages in parallel where the graph allows
  • Task dependencies — Packages build before apps that depend on them

Security considerations

Authentication

  • Session-based auth via Appwrite
  • HTTP-only cookies where applicable
  • CSRF-aware flows for state-changing operations
  • Role-based access control for admin capabilities

API and server boundaries

  • Sensitive keys stay on the server; only NEXT_PUBLIC_* values are browser-visible
  • Protected routes verify sessions server-side
  • Appwrite provides rate limiting and related controls

Payments

  • Card data is not stored in this codebase; Vipps handles PCI scope
  • Webhook handling should verify signatures and idempotency (see Payment package)

Environment variables

  • Secrets live in ignored env files (for example .env.local)
  • Public configuration uses the NEXT_PUBLIC_ prefix intentionally
  • Validate required env at startup for critical paths

Performance optimization

Build time

  • Turborepo task graph and caching
  • Incremental and parallel work

Runtime

  • Prefer Server Components to reduce client JavaScript
  • Static generation where content allows
  • next/image (or equivalent) for images
  • Code splitting and dynamic imports for heavy client-only UI

Bundle size

  • Shared @repo/ui and utilities reduce duplication
  • Tree shaking and careful client boundaries

Scalability

Horizontal scaling

  • Next.js apps are designed to be stateless at the instance level
  • Session state lives in Appwrite (not in-memory on a single node)

Vertical scaling and data tier

  • Appwrite and the database tier can be scaled independently of the web tier
  • Static assets can sit behind a CDN in production

Future directions

Possible evolutions (only if requirements grow): async workers/queues, dedicated API services, stronger CDN usage. No commitment to any single path — choose when there is measured need.

On this page