The Developer Sandbox is a personal development environment, technical reference system, project catalog, and experimental workspace. It is also a personal interface I use to display projects created as part of my ongoing learning and development work. It was built to bring different forms of development work into one organized system rather than maintaining a collection of unrelated project pages and reference files.

TThe Sandbox is designed to hold complete projects, development experiments, Rosetta Stone language comparisons, reference guides, data work, technical documentation, and other material that may need different presentation structures while still belonging to the same overall system.

Instead of forcing every item into one rigid page template, the system separates the identity of an item from the content used to construct its page. This makes the Sandbox useful both as a portfolio and as a long-term development knowledge base.

The system is divided into three primary layers: the public Sandbox interface, a structured SQLite datastore, and a local TypeScript and Node.js editor used to manage that data.

Developer Sandbox
│
├── Public Interface
│   ├── HTML
│   ├── CSS
│   ├── JavaScript
│   ├── Projects
│   ├── Reference Guides
│   └── Technical Documentation
│
├── SQLite Datastore
│   ├── Records
│   ├── Content Nodes
│   ├── Categories
│   ├── Tags
│   └── Technologies
│
└── Local Editor
    ├── TypeScript Client
    ├── Node.js Server
    ├── SQLite Operations
    ├── Content Preview
    └── Database / SQL Tools

The separation is intentional. Public presentation does not need the same permissions or capabilities as the authoring system. Editing, database writes, SQL operations, file access, and content management belong to the local development environment rather than the public-facing website.

The primary content object is an Entry stored in the records table. An Entry represents the identity of a Sandbox item: its title, slug, description, type, status, visibility, navigation information, presentation mode, and other catalog-level information.

Page content is stored separately as Content Nodes. This allows one Entry to contain multiple structured sections without requiring a different database table for every project or page design.

Content Nodes can be organized as top-level Parent Nodes and Child Nodes. Parent Nodes define major page structures while Child Nodes provide the content inside those structures. The hierarchy is deliberately limited to two levels to keep page structure understandable and manageable.

Entry
│
├── Parent Node
│   ├── Child Node
│   ├── Child Node
│   └── Child Node
│
├── Parent Node
│   ├── Child Node
│   └── Child Node
│
└── Parent Node

Parent Nodes can represent different visual structures such as navigation groups, display or preview areas, standard content, split layouts, responsive groups of boxes, and code or example sections. The type describes how content should be presented, while the stored content remains independent of a single hard-coded project page.

Additional node metadata can store presentation-specific information without requiring a new SQLite column every time the interface gains another optional feature. This provides a balance between a relational core schema and flexible page-level configuration.

A custom editor was built specifically for the Sandbox rather than adapting the project to an existing content-management system. The editor interface is written in TypeScript and communicates with a lightweight Node.js server.

The server opens the SQLite database with Node's SQLite support and provides the operations required by the editor. These include searching records, creating and updating Entries, creating and editing Nodes, changing node relationships, reordering content, deleting records or node trees, viewing database tables, and performing controlled SQL operations.

Multi-step database operations use SQLite transactions so related changes can succeed or fail as one operation. SQL validation uses a savepoint and rollback so a batch can be checked without committing its changes.

The Sandbox contains content that does not fit neatly into a conventional blog or portfolio CMS. A reference guide, code comparison, experiment, project case study, and data visualization may share common identity fields while requiring very different internal page structures.

Building the editor around the Sandbox data model makes the authoring workflow match the system rather than forcing the system to match a third-party editor. It also provides a practical environment for working with TypeScript, Node.js, SQLite, data modeling, CRUD operations, rendering logic, and development tooling as parts of one connected project.

The public Sandbox remains separate from the local authoring environment. The website presents projects, documentation, reference material, and technical work using the visual system shared across the Sandbox pages.

Database editing routes are part of the local development server, not a required public service. This keeps authoring capabilities separate from presentation while allowing the source code, database design, schema, and implementation to remain available for inspection in the repository.

Source code is organized so the static Sandbox interface, database files, database definitions, TypeScript source, and local editor remain identifiable as separate parts of the same application.

developer-sandbox/
│
├── assets/
│   ├── styles.css
│   ├── inner.css
│   ├── media.css
│   └── script.js
│
├── data/
│   └── sandbox.db
│
├── database/
│   ├── schema.sql
│   ├── editor-migration.sql
│   └── seed.sql
│
├── local-editor/
│   ├── index.html
│   ├── style.css
│   └── editor.config.json
│
├── src/
│   ├── datastore/
│   │   ├── database.ts
│   │   ├── queries.ts
│   │   └── types.ts
│   │
│   └── local-editor/
│       ├── client.ts
│       └── server.ts
│
├── index.html
├── inner.html
├── reference-guide.html
├── single-project.html
├── package.json
└── tsconfig.json

Shared TypeScript definitions describe Sandbox records, presentation modes, visibility states, status values, links, media, and content structures. Strict TypeScript compiler options are used so uncertainty in stored or optional data is handled deliberately rather than silently passed through the system.

This gives the datastore and editor a documented contract while still allowing the underlying SQLite schema to remain compact and understandable.

SQLite was selected because the Sandbox needs relational data and persistent local storage without requiring a separate database service. The database travels with the project, can be inspected directly, and supports the relationships and transactions needed by the editor.

TypeScript is used for the editor and datastore layer because the system contains many related object shapes, optional fields, status values, node types, and data transformations. Static HTML and CSS remain appropriate for the public interface because the Sandbox should remain lightweight and easy to host.

The result is intentionally hybrid: a simple public interface backed by a more capable local development system. The Sandbox itself becomes both the place where development work is presented and an ongoing software project demonstrating how that content is organized and maintained.