Skip to content
Korta

Documentation

What is this project?

Section titled “What is this project?”

Korta is a URL shortener created as a full-stack project to practice software architecture fundamentals. It follows a monolithic modular API approach in the backend and an Atomic Design architecture in the frontend.

Who is this for?

Section titled “Who is this for?”

Korta is ideal for marketers looking for a fast way to shorten URLs with basic analytics. It is also useful for developers who want a complete reference to build a URL-shortening application with a production-ready approach. The API also allows developers to generate their own API key and use the Korta backend in their own small-scale applications.

Documentation map

Section titled “Documentation map”
  • Getting Started
  • Product
  • API
  • Architecture
  • Operations
  • Reference

Naming conventions

Section titled “Naming conventions”
  • Primary language: TypeScript.
  • Variables and functions: camelCase.
  • Classes, types, interfaces, enums, and React components: PascalCase.
  • Global constants: UPPER_SNAKE_CASE.
  • Utility, service, and module files: kebab-case.ts.
  • React components: PascalCase.tsx filenames.
  • HTTP routes: kebab-case (e.g. /my-links, /verify-email).
  • Prisma models: singular PascalCase (User, Url).
  • Prisma/JSON API fields: camelCase (originalUrl, shortId, userId).

Code examples style

Section titled “Code examples style”
  • Every example should stay executable in realistic project context.
  • Include minimal context: endpoint, HTTP method, and expected payload.
  • Use code blocks with explicit languages: ts, tsx, bash, json.
  • Prioritize short examples focused on a single objective.
  • For APIs, always show: request, successful response, and a common error.
  • Use clear placeholders: YOUR_API_KEY, BASE_URL, SHORT_ID.
  • Keep naming consistent with real project entities (Url, User, /urls/my-links).

Versioning policy

Section titled “Versioning policy”
  • Semantic Versioning (MAJOR.MINOR.PATCH) is the target convention.
  • PATCH: fixes with no contract changes.
  • MINOR: backward-compatible features.
  • MAJOR: incompatible changes (breaking changes).
  • Public API changes should be reflected in changelog notes (maintained manually).
  • Release/versioning conventions are practiced manually by default (no automated enforcement tooling enabled out of the box).
  • Suggested release workflow:
  1. Keep main always stable.
  2. Use vX.Y.Z tags for each release when a versioned release is cut (recommended, not automated).
  3. Use Conventional Commits in commits and PRs (feat:, fix:, docs:, refactor:) as the current team convention; commitlint/hooks are not enforcing this today.