-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Welcome to the treemap wiki!
Table of Contents:
This is an API-first application, with backend written in Rust, and frontend written in TypeScript (Vue). For database, we use SQLite, for processing requests we use Amazon SQS (maybe a local queue implementation, also based on SQLite?).
Currently the only supported database is SQLite. It was chosen as the default option because it is serverless, can handle enormous numbers of simple queries, and quite a few updates. This usage profile fits the application needs perfectly. SQLite also requires almost zero hosting costs.
DynamoDB is another possible options, because it is serverless and requires no infrastructure set up, has pay per request billing, a significant free tier (25GB and 200M requests per month). It is tricky to run geospatial queries in DynamoDB efficiently. DynamoDB would mostly be valuable for diskless environments like DigitalOcean App Platform, so not the first thing to implement anyway.
Other serverless databases include MongoDB Atlas, App Engine, maybe something else.
When processing data updates, we use event sourcing to keep a history of updates.
See also database structure to understand current data structure.
All resource consuming operations are off-loaded from the web server process to queue consumers. Best case, all operations including data updates are performed via the queue, for rate limiting and error recovery.
Currently, there is a built in simple queue based on SQLite. The plans are to add support for SQS and Redis in future, if SQLite proves to be a bad option for this. (It sure prevents horizontal scaling.)
It should be possible to use an external file storage, probably based on S3. While the database can easily live on a small disk, even for a huge map, storing multiple photos for 1M of trees is going to require a lot of space. So an infinite storage is a requirement for any public service.
User experience:
- See user stories.
Backend:
- The application is distributed as a Docker container ready to run on any system.
- No compilation is needed, and no additional components need to be installed, other than the Docker infrastructure (or Podman).
Frontend:
- The frontend is compiled into static JavaScript files, requires no server side rendering.
- The distributed Docker container image contains the frontend files, configured to access the API as if it was running on the same host.
- Users are authenticated using Google and/or Apple auth providers, which are built into mobile phones.
Distribution:
- The app should be very easy to run. Like, a few shell commands to run a pre-compiled image that covers most needs.
- For complex installations, like distributed setups, an instruction should be written.