94e6b88cbe
- Frontend: HTML/CSS/JS demos and test pages - Backend: Go API with SQLite database - Features: AJAX calls, items management, random number generation - Database: SQLite with items table for CRUD operations 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
2.1 KiB
This is a test playground for web development - both frontend with simple html/css and vanilla javascript, and a backend API written in go.
Currently it is not a git repo, it's just an experiment.
IMPORTANT: This is a learning project for a non-developer. Always prioritize maximum simplicity and readability over "best practices". Use the most straightforward, beginner-friendly approaches possible. Avoid complex patterns, frameworks, or advanced techniques.
The current purpose: develop all basic features necessary for a simple browsergame along the lines of ogame - no realtime unit controls, currently no 3d graphics, just a "planet status" screen with buildings and researches, some buttons that call the api, and a map.
There is now a SQLite database available (items.db) with basic CRUD functionality. The database uses modernc.org/sqlite (pure Go, no CGO). Current tables:
itemstable: id (INTEGER PRIMARY KEY), name (TEXT) - used for the items management demo
remember to keep this file up to date if you change any of the points here.
Current folder structure: flat.
API Access
There is a reverse proxy rewrite rule in place. To call any API endpoint from the frontend, you need to add /api/ to the URL path:
- API endpoint URLs should be:
playground.shiny.space/api/yourendpointhere - Example:
/randomnumberendpoint becomes/api/randomnumber
Development
To rebuild the Go API after making changes:
- Run
go build -o apiin the project directory - The server has file watching enabled and will automatically restart with the new binary when it detects changes
Test Sites
The index.html file serves as the main navigation page listing all available test sites/demos. When creating new test HTML files, always add them to the feature list in index.html with a descriptive title and explanation.
Styling
All HTML pages use the unified styles.css file for consistent styling. Keep styling in this CSS file as much as reasonably possible - avoid inline styles in HTML files. It's perfectly fine to add new classes to styles.css for future tests and functionality. This approach keeps the test code much more readable and maintainable.