How phoccy/the-polyglot-workspace works
1. Repository purpose
- This is a polyglot sandbox demonstrating the same todo-style frontend being powered by one of four interchangeable backend implementations, all talking to the same SQLite database file.
2. Top-level split
- The repo is divided into two major runtime boundaries:
- Frontend/: a static client application.
- Backends/: four separate server implementations in different languages.
- There is also a shared Database/ concept in the README, but it is not tracked in the tree and is auto-created locally as todo.db.
3. Frontend subsystem
- Frontend/index.html, assets/css/styles.css, and assets/js/app.js form a single-page style vanilla web client.
- The frontend is intentionally backend-agnostic: it should work unchanged against any backend as long as the API contract remains consistent.
4. Client-to-server interaction
- The browser loads the static HTML/CSS/JS from the frontend folder.
- The JavaScript layer is the active integration point: it issues HTTP requests to localhost:8000 and renders the backend response.
- The frontend does not appear to own any persistence; it is a pure consumer of the API.
5. Shared API contract
- All four backends are designed to expose the same routes and payload shape.
- This is the key architectural boundary: the UI depends on the contract, not on language-specific implementation details.
- The README emphasizes that a backend can be stopped and replaced by another without changing the frontend.
6. SQLite persistence layer
- All backends use the same SQLite database file as the storage source.
- The database is local and file-based, which makes backend swapping possible without provisioning an external database service.
- The shared DB is the cross-runtime state boundary in the system.
7. PHP backend
- Backends/01-PHP/ is a standalone PHP server implementation.
- The presence of index.php, router.php, and config.php suggests a lightweight routed API built around PHP’s built-in server and PDO for SQLite access.
- This backend is one possible API provider for the frontend.
8. Python backend
- Backends/02-Python/server.py is a minimal Python server, likely built directly on the standard library http.server.
- It uses Python’s built-in SQLite support, making it another self-contained API host with minimal framework dependency.
9. C# backend
- Backends/03-CSharp/Program.cs with a .csproj indicates a .NET console/service-style HTTP server.
- The README notes HttpListener and Microsoft.Data.Sqlite, so this backend is an asynchronous listener that maps request data to C# models before hitting SQLite.
10. Java backend
- Backends/04-Java/src/com/todoapi/Server.java is a raw Java server using the JDK HttpServer.
- The README notes JDBC plus custom regex parsing, which implies the Java version performs its own route/parameter handling rather than relying on a higher-level web framework.
11. Port and deployment model
- Every backend is intended to listen on port 8000.
- Only one backend is meant to be active at a time, since they all occupy the same port and serve the same API shape.
- The architecture is therefore “single frontend + swappable backend runtime,” not a clustered or federated system.
12. Operational boundaries
- Each backend directory is an isolated execution environment with its own runtime toolchain:
- PHP runtime
- Python runtime
- .NET runtime
- JDK + SQLite JDBC dependencies
- This isolation is important for the diagram because the implementations are independent, but they converge on the same client contract and database file.
13. What to show in an architecture diagram
- A good diagram would center on three layers:
- Browser/frontend
- One of four backend implementations
- Shared SQLite database
- The critical visual idea is replaceability: the frontend connects to whichever backend is currently running, while the database remains the common persistence anchor.
Main entry points: app.js API client · index.php PHP API · server.py Python API · Program.cs C# API
Components 9
Frontend
Static client application
- HTML shell · Loads the single-page client
Frontend/index.html - Styles · Presentation layer for the client
Frontend/assets/css/styles.css - API client · Fetches data from the active backend and renders it
Frontend/assets/js/app.js
Backends
Four interchangeable API servers
- PHP API · Standalone PHP implementation of the todo API
Backends/01-PHP/index.php - Python API · Minimal Python implementation of the todo API
Backends/02-Python/server.py - C# API · .NET HTTP listener implementation of the todo API
Backends/03-CSharp/Program.cs - Java API · JDK HttpServer implementation of the todo API
Backends/04-Java/src/com/todoapi/Server.java
Data
Shared SQLite persistence
- todo.db · Shared local database used by every backend
Other components
- API contract · Common request and response shape shared by all backends
Connections 15
- HTML shell → Styles: loads · HTML references the stylesheet
- HTML shell → API client: loads · HTML boots the client script
- API client → API contract: uses · Client depends on the shared HTTP contract
- API client → PHP API: requests · Can talk to the PHP backend when it is active
- API client → Python API: requests · Can talk to the Python backend when it is active
- API client → C# API: requests · Can talk to the C# backend when it is active
- API client → Java API: requests · Can talk to the Java backend when it is active
- PHP API → API contract: implements · PHP server exposes the shared routes
- Python API → API contract: implements · Python server exposes the shared routes
- C# API → API contract: implements · C# server exposes the shared routes
- Java API → API contract: implements · Java server exposes the shared routes
- PHP API → todo.db: reads/writes · PHP backend persists to the shared SQLite file
- Python API → todo.db: reads/writes · Python backend persists to the shared SQLite file
- C# API → todo.db: reads/writes · C# backend persists to the shared SQLite file
- Java API → todo.db: reads/writes · Java backend persists to the shared SQLite file