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>
30 lines
2.1 KiB
Markdown
30 lines
2.1 KiB
Markdown
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:
|
|
- `items` table: 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: `/randomnumber` endpoint becomes `/api/randomnumber`
|
|
|
|
## Development
|
|
To rebuild the Go API after making changes:
|
|
- Run `go build -o api` in 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.
|