create-audora-next 0.1.7 → 2.0.1

package/templates/blog/src/blogs/content/cosketch/cosketch-canvas-engine.mdx

@@ -0,0 +1,186 @@
+---
+title: "How CoSketch's Canvas Engine Works"
+publishedAt: "2025-03-15"
+summary: "A conceptual walkthrough of the CoSketch canvas engine, from pointer events to state stores and React rendering."
+description: "A conceptual walkthrough of the CoSketch canvas engine, from pointer events to state stores and React rendering."
+date: "2025-03-15"
+tags:
+  - canvas
+  - architecture
+  - frontend
+  - state-management
+  - cosketch
+repoUrl: "https://github.com/NarsiBhati-Dev/cosketch"
+---
+
+## Why a dedicated canvas engine?
+
+CoSketch is a real-time collaborative whiteboard where multiple people draw and edit shapes on a shared canvas. It needs to support real-time collaboration, multiple shapes and tools, smooth interactions, and synchronization over WebSockets. To manage that complexity, the project centralizes all drawing logic in a **canvas engine** instead of scattering the rules across React components.
+
+The engine pipeline in `apps/cosketch-frontend/src/canvas_engine/` defines how pointer events become shapes on the screen. React components in `apps/cosketch-frontend/src/components/canvas/` focus on UI and layout, while state stores in `apps/cosketch-frontend/src/stores/` keep the shared canvas state consistent and serializable.
+
+> In short: pointer events go to the engine, the engine updates stores, and React components render from those stores.
+
+## The core engine modules
+
+The canvas engine is implemented as a set of focused modules under `apps/cosketch-frontend/src/canvas_engine/`:
+
+- [`CanvasEngine.ts`](https://github.com/narsibhati-dev/cosketch/blob/master/apps/cosketch-frontend/src/canvas_engine/CanvasEngine.ts): orchestrates tools, shapes, and event handling.
+- [`SelectionManager.ts`](https://github.com/narsibhati-dev/cosketch/blob/master/apps/cosketch-frontend/src/canvas_engine/SelectionManager.ts): encapsulates logic for tracking and manipulating selected shapes.
+- [`eraser.ts`](https://github.com/narsibhati-dev/cosketch/blob/master/apps/cosketch-frontend/src/canvas_engine/eraser.ts): provides erasing behavior and hit-testing helpers.
+
+From a conceptual standpoint, `CanvasEngine` is the **central coordinator**:
+
+- It receives low-level pointer events from React components (`pointerdown`, `pointermove`, `pointerup`).
+- It consults the **current tool** and canvas state to decide what to do (draw, move, resize, erase, select).
+- It updates one or more shared stores to reflect the new canvas state.
+
+`SelectionManager` and `eraser` are specialized collaborators that plug into this flow, but they do not render UI themselves.
+
+## State stores: the source of truth
+
+The canvas engine heavily relies on a set of dedicated stores under `apps/cosketch-frontend/src/stores/`:
+
+- [`tool.store.ts`](https://github.com/narsibhati-dev/cosketch/blob/master/apps/cosketch-frontend/src/stores/tool.store.ts)
+- [`canvas.store.ts`](https://github.com/narsibhati-dev/cosketch/blob/master/apps/cosketch-frontend/src/stores/canvas.store.ts)
+- [`canvas_style.store.ts`](https://github.com/narsibhati-dev/cosketch/blob/master/apps/cosketch-frontend/src/stores/canvas_style.store.ts)
+- [`shape_selected.store.ts`](https://github.com/narsibhati-dev/cosketch/blob/master/apps/cosketch-frontend/src/stores/shape_selected.store.ts)
+
+At a high level, each store has a distinct responsibility:
+
+- **Tool store (`tool.store.ts`)**: which tool is active (e.g., rectangle, ellipse, diamond, arrow, line, freehand, text, eraser, move).
+- **Canvas store (`canvas.store.ts`)**: the actual shapes, their geometry, and any serialized representation of the canvas.
+- **Canvas style store (`canvas_style.store.ts`)**: stroke color, fill color, line width, and other styling options.
+- **Selection store (`shape_selected.store.ts`)**: which shapes are currently selected and how they are being manipulated.
+
+React components subscribe to these stores to stay in sync, while the canvas engine writes updates to them in response to user actions and incoming collaboration events.
+
+> Data flows from the tool and canvas-style stores into the canvas store when shapes are created or updated; the selection store tracks what is selected.
+
+## From pointer events to shapes
+
+The pipeline from a user’s pointer event to a rendered shape is conceptually straightforward but implemented with many moving parts.
+
+For instance, when you draw a rectangle: the UI fires pointerdown at the start point, pointermove as you drag, and pointerup when you release. The engine creates a rectangle primitive, updates it on each pointermove, and writes the final shape to the canvas store. React subscribes to the store and re-renders, so the new rectangle appears on screen and can be synced to other users.
+
+### 1. UI captures the event
+
+React components in `apps/cosketch-frontend/src/components/canvas/` (such as `canvas.tsx`, toolbar, and sidebar) are responsible for attaching event listeners to the drawing surface. When a user interacts with the canvas:
+
+- `pointerdown` marks the beginning of a gesture.
+- `pointermove` tracks the gesture over time (for drawing or dragging).
+- `pointerup` finalizes the gesture and commits changes.
+
+These components do not interpret the event in terms of shapes. Instead, they call into `CanvasEngine` with a normalized event object.
+
+For example, a simplified handler might look like:
+
+```tsx
+canvasEngine.handlePointerDown({
+  x: event.clientX,
+  y: event.clientY,
+  pointerId: event.pointerId,
+});
+```
+
+### 2. Engine consults the current tool
+
+Inside `CanvasEngine`, the next step is to determine what the user intends to do by checking the active tool from `tool.store.ts`. The logic is conceptually:
+
+The real implementation may use a map of tool handlers; this switch illustrates the idea:
+
+```ts
+const currentTool = toolStore.getState().currentTool;
+
+switch (currentTool) {
+  case "rectangle":
+    // start a new rectangle
+    break;
+  case "arrow":
+    // start a new arrow
+    break;
+  case "text":
+    // place or edit text
+    break;
+  case "eraser":
+    // delegate to eraser behavior
+    break;
+  case "selection":
+    // delegate to SelectionManager
+    break;
+}
+```
+
+Each tool has its own conventions:
+
+- **Rectangle / ellipse / diamond**: usually start from an origin point and expand as the pointer moves.
+- **Arrow / line**: defined by a start and end point.
+- **Freehand**: a polyline or spline constructed from many pointer samples.
+- **Text**: placing a text box and then managing text editing separately.
+
+### 3. Updating the stores
+
+As the engine interprets pointer events, it updates the relevant stores:
+
+- New shapes are added to `canvas.store.ts`.
+- Style information is pulled from `canvas_style.store.ts` and attached to shapes.
+- Selection state may be updated in `shape_selected.store.ts` if the tool implies selection changes.
+
+Because stores are the source of truth, React components re-render automatically as the data changes, and the WebSocket layer can serialize store changes for collaboration.
+
+## UI components around the engine
+
+The engine and stores do not render anything by themselves—the user sees the canvas and controls through React components. The React components in `apps/cosketch-frontend/src/components/canvas/` provide the user-facing controls that drive the engine:
+
+- Toolbar and buttons in `components/canvas/toolbar/` let users choose tools and actions.
+- Sidebar components in `components/canvas/sidebar/` expose shape and color options.
+- Footer components in `components/canvas/footer/` manage zoom, status indicators, and encryption display.
+
+These components:
+
+- Read from stores (e.g., which tool is active, current zoom level).
+- Dispatch actions to change store values (e.g., selecting a new tool or color).
+- Call engine methods when significant pointer or keyboard events occur.
+
+The key design decision is that the **React layer is thin**: it owns DOM and layout, while the engine and stores own business logic and state.
+
+> Toolbar, sidebar, and footer wrap the canvas and talk to the engine and stores; they do not contain drawing logic.
+
+## Shapes and internal primitives
+
+While the exact shape models live in the code, conceptually each visual object on the canvas is represented as a **shape primitive** with:
+
+- A type (rectangle, ellipse, diamond, arrow, line, freehand, text).
+- Geometry (position, size, path data).
+- Style (stroke color, fill color, line width, opacity).
+- Metadata (e.g., ID, timestamps, ownership or author).
+
+The engine adds and mutates these primitives within the canvas store as tools are used. For example:
+
+- Drawing a rectangle creates a new rectangle primitive and updates it during `pointermove`.
+- Moving a group of shapes updates their positions while preserving IDs so other clients can reconcile changes.
+- Text primitives may contain additional fields for the text content and font properties.
+
+Because shapes are plain data objects, they are easy to:
+
+- Serialize over WebSockets.
+- Persist via the backend API.
+- Re-apply when clients reconnect.
+
+## Lessons learned & design trade-offs
+
+A few takeaways from building the engine:
+
+- **Separation of concerns**: Keeping canvas logic in `canvas_engine` and state in stores helps avoid React components becoming overly complex and difficult to test.
+- **Data-first design**: Representing shapes as serializable data structures makes collaboration and persistence natural but requires more discipline in versioning the shape schema.
+- **Tool-centric interaction**: Routing all input through the current tool simplifies reasoning about behavior, but it adds a layer of indirection that developers must learn.
+
+## What’s next
+
+For how eraser and selection fit into this pipeline, see [Eraser & Selection Mechanics](/blogs/cosketch-eraser-and-selection).
+
+Future evolution of the canvas engine might include:
+
+- More sophisticated snapping and alignment features, implemented as separate modules that hook into `CanvasEngine`.
+- A richer plugin system for tools so new shapes and behaviors can be added without changing core engine code.
+- Optimizations for very large canvases, including offscreen rendering and more granular updates to minimize re-renders.

package/templates/blog/src/blogs/content/cosketch/cosketch-docker-architecture.mdx

@@ -0,0 +1,175 @@
+---
+title: "Inside CoSketch's Docker & Docker Compose Architecture"
+publishedAt: "2025-04-10"
+summary: "A conceptual tour of how CoSketch uses Docker, Docker Compose, Bun, and Turborepo to run the frontend, backend API, WebSocket server, and PostgreSQL database."
+description: "A conceptual tour of how CoSketch uses Docker, Docker Compose, Bun, and Turborepo to run the frontend, backend API, WebSocket server, and PostgreSQL database."
+date: "2025-04-10"
+tags:
+  - docker
+  - docker-compose
+  - infrastructure
+  - architecture
+  - cosketch
+repoUrl: "https://github.com/NarsiBhati-Dev/cosketch"
+---
+
+## Why CoSketch cares about containers
+
+CoSketch is a real-time collaborative whiteboard with a rich frontend, an HTTP backend, a WebSocket server, and a PostgreSQL database. Running all of these pieces consistently across machines is hard if you rely only on local tooling, language runtimes, and environment configuration.
+
+Containers give CoSketch a **repeatable, declarative runtime** for each service. Docker images built from the production Dockerfiles in `docker/` can be launched locally, in CI, or in production with predictable behavior. Docker Compose then layers orchestration on top, wiring the services together and defining how they start and talk to each other.
+
+> In short: the frontend, backend, WebSocket server, and PostgreSQL database run as separate containers; Docker Compose wires them together over a shared network.
+
+## The containerized services in CoSketch
+
+At a conceptual level, CoSketch runs four main services in containers:
+
+- **Frontend (Next.js + React)**: the user-facing app in `apps/cosketch-frontend/`.
+- **Backend API (REST)**: the HTTP API implemented in `apps/cosketch-backend/`.
+- **WebSocket server**: a dedicated real-time collaboration service in `apps/cosketch-websocket/`.
+- **PostgreSQL database**: the persistent data store managed via the `packages/database` package and Prisma migrations.
+
+Each of the application services is built using a dedicated production Dockerfile in the `docker/` directory:
+
+- `docker/backend.prod.Dockerfile`
+- `docker/frontend.prod.Dockerfile`
+- `docker/websocket.prod.Dockerfile`
+
+These Dockerfiles encapsulate how code is copied, dependencies are installed, and the runtime entrypoint is defined for each service.
+
+> Each Dockerfile produces an image; the frontend, backend, and WebSocket services connect to the database and to each other as defined in the Compose file.
+
+## Reading the production Dockerfiles
+
+Even without looking at every line, it helps to build a mental model of what the Dockerfiles in `docker/` are doing.
+
+### Backend image (`backend.prod.Dockerfile`)
+
+The backend service at `apps/cosketch-backend/` exposes REST endpoints for authentication, rooms, and canvas persistence. Conceptually, the backend Dockerfile:
+
+- **Selects a base image** with Node/Bun that matches the backend’s runtime.
+- **Copies the monorepo or relevant app subtree** into the image.
+- **Installs dependencies** for the backend and any shared packages (such as `packages/database` and `packages/backend-common`).
+- **Runs build scripts** (driven by Turborepo at the root `package.json`) to emit compiled JavaScript.
+- **Defines an entrypoint** that starts the backend server (often `bun run start` or similar) and binds to the container’s HTTP port.
+
+From the codebase perspective, this image is responsible for serving logic found under:
+
+- `apps/cosketch-backend/src/server.ts`
+- `apps/cosketch-backend/src/routes/*`
+- `apps/cosketch-backend/src/controllers/*`
+
+### Frontend image (`frontend.prod.Dockerfile`)
+
+The frontend service at `apps/cosketch-frontend/` is a Next.js app. Its Dockerfile typically:
+
+- Builds the Next.js app using the monorepo build pipeline (Turborepo).
+- Produces optimized static assets and server-side bundles.
+- Uses a runtime image with only the pieces needed to serve the built app.
+
+Conceptually, that means the Dockerfile:
+
+- Installs dependencies for the frontend app and shared packages.
+- Runs a build command such as `bun run build` or a Turborepo target that triggers the Next.js production build.
+- Sets the entrypoint to run the Next.js server (or a minimal Node/Bun process that serves the built output).
+
+This image serves application code from:
+
+- `apps/cosketch-frontend/src/app/**`
+- Canvas UI components in `apps/cosketch-frontend/src/components/canvas/**`
+- Hooks, stores, and other frontend helpers under `apps/cosketch-frontend/src/**`.
+
+### WebSocket image (`websocket.prod.Dockerfile`)
+
+Real-time collaboration in CoSketch is handled by the WebSocket server in `apps/cosketch-websocket/`. This Dockerfile:
+
+- Focuses on the WebSocket process and its dependencies.
+- Copies the relevant source (`apps/cosketch-websocket/src/**`) into the image.
+- Installs only what is needed to run the WebSocket server.
+- Exposes the WebSocket port and defines an entrypoint to start `server.ts`.
+
+From the code, the WebSocket image is the runtime home for:
+
+- `apps/cosketch-websocket/src/server.ts`
+- Handlers in `apps/cosketch-websocket/src/handlers/**`
+- Auth and token utilities in `apps/cosketch-websocket/src/services/**`
+
+> Clients hit the frontend, upgrade to WebSocket for real-time collaboration, and the WebSocket server relays canvas and presence messages between users.
+
+## Docker Compose: composing the stack
+
+While Dockerfiles describe **how to build images**, Docker Compose describes **how to run them together**. CoSketch uses:
+
+- A root `docker-compose.yml` for orchestrating the main stack.
+- `docker/db.docker-compose.yml` (and related files) for database-focused or infrastructure-only scenarios.
+
+Conceptually, `docker-compose.yml` defines:
+
+- **Services**: frontend, backend, websocket, and database containers.
+- **Networks**: how containers discover each other (service names become hostnames).
+- **Volumes**: persistence for PostgreSQL data.
+- **Environment variables**: configuration such as database URLs, JWT secrets, and frontend API endpoints.
+
+The application services referenced in the Compose file are built from the images whose definitions live in:
+
+- `docker/frontend.prod.Dockerfile`
+- `docker/backend.prod.Dockerfile`
+- `docker/websocket.prod.Dockerfile`
+
+> The Compose file defines the four services and a shared bridge network so they can reach each other by service name.
+
+## Bun and Turborepo inside containers
+
+CoSketch uses **Bun** and **Turborepo** at the monorepo root to manage builds and scripts. The root `package.json` contains scripts that orchestrate infra and dev flows, such as:
+
+- `infra:up`
+- `infra:down`
+- `db:up`
+- `db:down`
+
+In a Dockerized environment, Bun and Turborepo serve two main purposes:
+
+- **Build orchestration**: A single Turborepo target can build multiple apps (`cosketch-backend`, `cosketch-frontend`, `cosketch-websocket`) and shared packages (`packages/database`, `packages/types`, etc.) before images are finalized.
+- **Unified commands**: The same scripts can be used locally and in CI to ensure that images are always built in a consistent way.
+
+From a conceptual standpoint, the Dockerfiles often:
+
+1. Install Bun and dependencies once at the root.
+2. Run Turborepo build commands to compile all relevant apps.
+3. Copy only the compiled output and necessary runtime files into the final image layers.
+
+This keeps runtime images smaller and builds deterministic across environments.
+
+## Local vs. production container flows
+
+Even if you run CoSketch differently in local development and in production, the mental model is similar:
+
+- **Local dev**:
+  - You may run some services directly with `bun dev` or similar commands.
+  - Compose is often used for the database and sometimes for the full stack when you want environment parity.
+- **Production**:
+  - All application services run as containers built from the production Dockerfiles.
+  - Docker Compose (or an orchestrator like Kubernetes) manages replicas, restarts, and shared networks.
+
+The root `docker-compose.yml` is effectively a **declarative recipe** for a full CoSketch stack, which can anchor both environments.
+
+> The same images can run on a developer machine or in a production cluster; Compose (or another orchestrator) defines how they are started and connected.
+
+## Lessons learned & design trade-offs
+
+A few takeaways from building the stack:
+
+- **Image boundaries matter**: Separating frontend, backend, and WebSocket into distinct images mirrors their responsibilities in the codebase and allows independent scaling.
+- **Monorepo + Docker**: Using Turborepo and shared packages (`packages/database`, `packages/types`) means Docker builds need to be aware of the workspace structure, but the payoff is consistent types and logic across services.
+- **Compose as documentation**: The `docker-compose.yml` file is not just an orchestration tool—it doubles as executable documentation for how CoSketch’s services relate.
+
+## What’s next
+
+For how the frontend canvas engine works inside the app, see [How CoSketch's Canvas Engine Works](/blogs/cosketch-canvas-engine).
+
+Future improvements to CoSketch’s container story might include:
+
+- Adding health checks and better observability into the images (e.g., `/healthz` endpoints and metrics scraping).
+- Splitting build and runtime stages further to minimize image size.
+- Introducing more sophisticated orchestration (Kubernetes, Nomad, etc.) using the existing images as a foundation.

package/templates/blog/src/blogs/content/cosketch/cosketch-eraser-and-selection.mdx

@@ -0,0 +1,207 @@
+---
+title: "Eraser & Selection Mechanics in CoSketch"
+publishedAt: "2025-05-01"
+summary: "A deep dive into how CoSketch handles erasing and selecting shapes in its canvas engine, and how those changes propagate to collaborators."
+description: "A deep dive into how CoSketch handles erasing and selecting shapes in its canvas engine, and how those changes propagate to collaborators."
+date: "2025-05-01"
+tags:
+  - canvas
+  - eraser
+  - selection
+  - collaboration
+  - cosketch
+repoUrl: "https://github.com/NarsiBhati-Dev/cosketch"
+---
+
+## Why erasing and selection are hard problems
+
+CoSketch is a real-time collaborative whiteboard where multiple people draw and edit shapes on a shared canvas. On a simple drawing app, an eraser might just paint white pixels and selection might be little more than a single highlighted object. CoSketch, however, needs to support:
+
+- **Multiple shape types** (rectangles, ellipses, diamonds, arrows, lines, freehand paths, text).
+- **Real-time collaboration**, where changes must be synchronized over WebSockets.
+- **Consistent state** across the frontend stores, backend persistence, and other clients.
+
+To achieve this, CoSketch centralizes eraser and selection behavior in the canvas engine modules:
+
+- [`eraser.ts`](https://github.com/NarsiBhati-Dev/cosketch/blob/master/apps/cosketch-frontend/src/canvas_engine/eraser.ts)
+- [`SelectionManager.ts`](https://github.com/NarsiBhati-Dev/cosketch/blob/master/apps/cosketch-frontend/src/canvas_engine/SelectionManager.ts)
+
+These modules work with shared stores and the WebSocket layer to transform user gestures into deterministic, shareable canvas updates.
+
+> In short: the eraser defines a hitbox along the pointer path; any shape that intersects that region is removed or trimmed, and the canvas store is updated so all clients stay in sync.
+
+## Eraser behavior in `eraser.ts`
+
+The `eraser.ts` module is responsible for turning a user’s erasing gesture into updates on the underlying shapes. Conceptually, the eraser tool:
+
+- Tracks the pointer path while the eraser is active.
+- Builds a **hitbox region** around the pointer path (often a circle or rectangle sized by eraser thickness).
+- Performs hit-testing against shapes and freehand paths intersecting the hitbox.
+- Updates the canvas store to remove or modify affected shapes.
+
+The eraser works hand-in-hand with the active tool logic in `CanvasEngine.ts`:
+
+- When the current tool is `"eraser"`, pointer events are routed to eraser-specific handlers.
+- The eraser module receives information about the pointer’s position and the current canvas state.
+- It computes which shapes are impacted and returns a set of changes for the engine to apply to stores.
+
+At a high level, the eraser flow looks like this:
+
+```ts
+// Pseudocode for eraser integration
+canvasEngine.handlePointerMove(event, () => {
+  if (toolStore.getState().currentTool === "eraser") {
+    const changes = eraser.computeEraseChanges({
+      pointerPath,
+      shapes: canvasStore.getState().shapes,
+    });
+
+    canvasStore.getState().applyChanges(changes);
+  }
+});
+```
+
+The actual implementation may use more efficient data structures and batch updates to minimize re-renders and network chatter, but the conceptual pipeline remains the same.
+
+## Hit-testing shapes and freehand paths
+
+Hit-testing is the process of determining which shapes the eraser intersects. CoSketch must support:
+
+- **Geometric shapes** (rectangles, ellipses, diamonds).
+- **Linear shapes** (arrows, lines).
+- **Freehand paths**, typically represented as polylines.
+
+For each shape type, `eraser.ts` or related utilities can use:
+
+- **Bounding box checks** as a cheap first filter.
+- **More precise geometry checks** (e.g., distance from a line segment, point-in-ellipse tests, or polyline distance sampling).
+
+For freehand paths, the common pattern is:
+
+- Sample the path as a sequence of points.
+- For each eraser sample point or segment, check if the distance to any path segment is below an eraser threshold.
+- If the path is partially erased, either:
+  - Split it into multiple smaller paths, or
+  - Remove it entirely if the majority is hit (depending on UX decisions).
+
+The result of hit-testing is a list of shapes (and sometimes sub-paths) that need to be updated or removed from the canvas store.
+
+> The eraser samples the pointer path and checks distance to each path segment; segments within the eraser threshold are removed or split, producing updated primitives for the canvas store.
+
+## Updating shared canvas state on erase
+
+Once `eraser.ts` identifies the impacted shapes, it transforms that information into state updates:
+
+- **Shape deletion**: shapes fully covered by the eraser hitbox are removed from `canvas.store.ts`.
+- **Shape modification**: paths or complex shapes may be trimmed or split, resulting in a set of new primitives replacing the old one.
+- **Selection cleanup**: any shapes currently selected that are erased must also be removed from the selection state in `shape_selected.store.ts`.
+
+Because the stores are the single source of truth, all downstream systems see the same result:
+
+- React components re-render without the erased shapes.
+- The WebSocket synchronization layer serializes the changes and sends them to other clients.
+- The backend can persist the updated canvas representation.
+
+From the engine’s perspective, erasing is just another state transition on the same shape model used for drawing and moving.
+
+## Selection mechanics via `SelectionManager.ts`
+
+Selection is managed by the `SelectionManager` module in `apps/cosketch-frontend/src/canvas_engine/SelectionManager.ts`. This module encapsulates:
+
+- How the app decides what is "currently selected".
+- How bounding boxes and drag handles are computed.
+- How multi-select and group operations work.
+
+The typical selection lifecycle goes through several conceptual states:
+
+1. **Idle**: no active selection, or selection is present but not being modified.
+2. **Hover**: the pointer is over a shape or a selection handle, highlighting potential actions.
+3. **Selected**: one or more shapes are selected; a bounding box and handles may be shown.
+4. **Dragging / Resizing**: the user drags the selection or a handle to move or resize shapes.
+
+`SelectionManager` works closely with:
+
+- `shape_selected.store.ts` for storing selected IDs and transient selection metadata.
+- `canvas.store.ts` for reading the latest positions and sizes of shapes.
+- `tool.store.ts` to interpret intent (e.g., whether the user is using a selection tool or a direct manipulation tool).
+
+> Selection moves through idle, hover, selected, and dragging or resizing; the selection store and canvas store stay in sync so handles and bounding boxes reflect the current state.
+
+## Bounding boxes, handles, and multi-select
+
+To provide a good UX, CoSketch uses bounding boxes and drag handles around selections:
+
+- For a single shape, the bounding box closely wraps that shape.
+- For multiple shapes, the box encompasses all selected shapes.
+
+`SelectionManager` computes this envelope by:
+
+- Reading the geometry from `canvas.store.ts` for all selected shapes.
+- Computing the min/max of x and y coordinates to form a bounding rectangle.
+- Deriving handle positions (corners, edges, possibly rotation handles).
+
+Multi-select can be initiated by:
+
+- Clicking while holding a modifier key (e.g., Shift).
+- Dragging a marquee (selection rectangle) that intersects multiple shapes.
+
+The resulting selection is stored in `shape_selected.store.ts`, which might include:
+
+- A list of selected shape IDs.
+- The current bounding box.
+- Flags for whether the user is currently dragging, resizing, or rotating.
+
+The engine then applies transformations (translation, scaling, rotation) to the underlying shapes when the user drags the selection or a handle, updating `canvas.store.ts` accordingly.
+
+## Interactions between selection and tools
+
+Selection doesn’t exist in isolation; it interacts with other tools:
+
+- **Move / selection tool**: directly manipulates selected shapes.
+- **Style tools**: changes color, stroke width, or other properties of the selection via `canvas_style.store.ts`.
+- **Delete / eraser tools**:
+  - A delete action may remove all selected shapes at once.
+  - The eraser may implicitly change the current selection if it modifies or removes shapes under the cursor.
+
+`SelectionManager` and `eraser.ts` must coordinate to keep the selection store consistent when shapes are modified or removed. For example:
+
+- If a selected shape is erased, `shape_selected.store.ts` must remove that shape ID from the selection.
+- If a shape is split into multiple shapes, the selection state may choose to select the new shapes or clear the selection depending on UX rules.
+
+This coordination ensures that users never see stale handles or bounding boxes attached to shapes that no longer exist.
+
+## WebSocket synchronization of erasing and selection
+
+CoSketch uses the WebSocket server in `apps/cosketch-websocket/` to keep multiple clients in sync. While exact message formats are defined in the code, conceptually:
+
+- The frontend sends **canvas update messages** when:
+  - Shapes are added, moved, resized, or deleted.
+  - Eraser operations result in shape modifications.
+- Other clients apply these updates to their own stores, reproducing the same erasing and selection state transitions.
+
+Selection state itself may or may not be fully synchronized (depending on design), but the **underlying shape updates definitely are**. For example:
+
+- If you erase part of a freehand stroke, your client computes the resulting shapes and sends a message describing those changes.
+- Other clients remove or adjust the same shapes in their canvas store, even if their local selection differs.
+
+This design keeps the core canvas data model consistent across all participants, while allowing some local freedom (such as independent selection state).
+
+> One client applies an erase; the WebSocket server relays the canvas update; other clients apply the same changes to their stores so everyone sees the same canvas.
+
+## Lessons learned & design trade-offs
+
+A few takeaways from building eraser and selection:
+
+- **Geometry vs. UX**: Accurate hit-testing and shape splitting can be complex; CoSketch balances precision with performance and a reasonable mental model for users.
+- **State consistency**: Centralizing shape and selection state in stores simplifies reasoning, but requires careful coordination between eraser, selection, and other tools.
+- **Collaboration granularity**: Sending fine-grained canvas updates over WebSockets enables smooth collaboration but must be batched or compressed to avoid overwhelming the network.
+
+## What’s next
+
+For the broader canvas engine pipeline (pointer events, stores, and tools), see [How CoSketch's Canvas Engine Works](/blogs/cosketch-canvas-engine).
+
+Potential future improvements to eraser and selection mechanics in CoSketch include:
+
+- More advanced partial-erasing behavior for freehand strokes with visual previews.
+- Improved visual feedback for multi-select (e.g., per-shape outlines plus a group box).
+- Conflict resolution strategies when multiple collaborators erase or modify the same shapes simultaneously.

package/templates/blog/src/blogs/content/hello-world.mdx

@@ -0,0 +1,66 @@
+---
+title: "Hello World in Rust with Axum"
+publishedAt: "2026-01-03"
+summary: "A minimal Hello World web server using Rust and the Axum framework."
+description: "A minimal Hello World web server using Rust and the Axum framework."
+date: "2026-01-03"
+tags:
+  - rust
+  - axum
+  - web
+---
+
+**Axum** is a fast, ergonomic web framework for Rust built on [Tokio](https://tokio.rs/) (async runtime) and [Tower](https://github.com/tower-rs/tower) (middleware). In this post we’ll build a minimal “Hello, World!” server you can run in a few minutes.
+
+## Setup
+
+Create a new project and add the dependencies:
+
+```bash
+cargo new hello-axum
+cd hello-axum
+```
+
+In `Cargo.toml`:
+
+```toml
+[dependencies]
+axum = "0.7"
+tokio = { version = "1", features = ["full"] }
+```
+
+## The server
+
+In `src/main.rs`:
+
+```rust
+use axum::{routing::get, Router};
+
+#[tokio::main]
+async fn main() {
+    let app = Router::new().route("/", get(handler));
+
+    let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await.unwrap();
+    axum::serve(listener, app).await.unwrap();
+}
+
+async fn handler() -> &'static str {
+    "Hello, World!"
+}
+```
+
+## Run it
+
+```bash
+cargo run
+```
+
+Open [http://localhost:3000](http://localhost:3000) and you should see **Hello, World!**.
+
+## What’s going on
+
+- **Router** – Defines routes; here we attach a single `GET /` to `handler`.
+- **handler** – An async function that returns a string; Axum sends it as `text/plain` with status 200.
+- **tokio::main** – Runs the async runtime so `main` can `await`.
+
+From here you can add more routes, JSON with `axum::Json`, and middleware from the Tower ecosystem.