Wormhole's architecture will be as follows:
|---> [Frontend]
|
[Backend] ------|---> [Query Service]
|
|---> [Database]
The backend acts as a sort of control plane. It orchestrates the rest of the components and runs the app. The backend will also house the main API which can be used by plugins.
The frontend will either be the CLI or the GUI.
The GUI is powered by Tauri, and uses the SvelteKit framework to do its rendering logic. The basic flow will be:
- Home
- Game list
- [Game]
- Instances
- [Instance]
- Manage mods:
- Browse & add mods
- Remove mods based on a list
- List contains:
- Mod name
- File name
- File size
- Modified date
- List contains:
- Update description
- View log outputs
- Manage instance-specific settings
- Manage mods:
- Create
- Instance created
- Redirect to its page
- [Instance]
- Settings
- Change game path
- Log in to game accounts
- Instances
- [Game]
- Settings
- Game list
For the CLI, there will be a few commands:
NOTE: wh
is an alias for wormhole
.
wh version
- Print version informationwh gui
- Open the GUI versionwh game list
- List installed gameswh game detect
- Detect installed gameswh game remote
- List supported gameswh game install [game]
- Install a game (using the proper launcher)wh game uninstall [game]
- Uninstall a game (using the proper launcher)wh game info [game]
- Print information about a gamewh inst(ance) [game] (list)
- List instanceswh inst [game] add
- Open a prompt interface to create a new instancewh inst [game] del [name]
- Remove an instancewh inst [game] mods [name]
- List mods for an instancewh inst [game] mods [name] add [mod]
- Add a mod to an instancewh inst [game] mods [name] del [mod]
- Remove a mod from an instancewh inst [game] mods [name] update ([mod]...)
- Update all mods for an instancewh update
- Check for updateswh cache info
- Get information about cache usagewh cache prune
- Prune cached fileswh reset
- Reset and remove all instances and installed games, clearing all data.
The CLI will be installed alongside the GUI.
The Query Service manages mod sources and indexing. This handles searching for mods, getting metadata, retaining metadata, and much more.
Mod sources:
- Spacedock (supported)
- CKAN (WIP) (crate)
- CurseForge (planned)
- Modrinth (planned)
- Thunderstore (planned)
- Nexus Mods (planned*)
- More?**
* Nexus mods is dependent on the developer friendliness and capability of its API. ** More can be suggested! Go to the repository discussions tab and suggest there!
The Query Service will also cache some results into the database to aid in not spamming these services. These cached results will mostly include mod version-specific metadata, and NOT dynamic data like version lists, general mod metadata, and search results.
The database will be powered by sqlite (rusqlite) and will provide metadata storage about installed games, instances, mod lists, modpacks, plugins, settings, and cache information.
Modpacks will be supported! A special .whmp
(WormHole ModPack) format will be used to share modpacks.
These can then be uploaded to Wormhole's custom registry and shared publicly.
Plugins will be implemented by using a runtime WASI plugin loader and will be written in Rust. These will have full access to Wormhole's API and system details. BE CAREFUL!
The implementation will be like this.
- Load the WASI (
.wasm
) module. - Dynamically execute the contained initializer.