Background Services & Workers - Incomplete-Infinity/eve-companion GitHub Wiki

🛠 Background Services & Workers

This page outlines how the EVE Companion App uses background services and Web Workers to handle heavy tasks, parallelize operations, and keep the UI responsive. This architecture allows for real-time processing, caching, and network operations outside of the main thread.


🎯 Goals

  • Offload expensive tasks from the main UI thread
  • Enable persistent services (e.g., polling, caching)
  • Parallelize data collection from ESI or logs
  • Prepare foundation for real-time sync across modules

🧩 Worker Roles

Worker Name Responsibility
apiWorker Queueing and batching ESI requests, auto-retries, token refresh
marketWorker Handling price updates, profit calculations
fitWorker Fit parsing, stat calculation, doctrine matching
fleetWorker Member polling, MOTD updates, fleet role tallying
scannerWorker D-Scan parsing and position estimation

Each worker is responsible for a functional domain and communicates via message-passing.


🧬 Architecture

Workers are managed by a controller layer in the main process:

const worker = new Worker(new URL('./apiWorker.js', import.meta.url));
worker.postMessage({ action: 'fetch', url: '/universe/types/' });
worker.onmessage = (e) => {
  // handle result
};

Message schemas are standardized and versioned.


💡 Persistent Background Tasks

Some tasks run continuously:

  • Polling fleet data every N seconds
  • Watching clipboard for fit imports
  • Refreshing market stats hourly
  • Cleaning expired cache entries

Timers and state are isolated per worker to avoid cross-talk.


⚙️ Electron-Specific Workers

In Electron, long-running services can be implemented either as:

  • Web Workers (in renderer)
  • Node.js background services (in main process)
  • Dedicated Electron preload threads (advanced)

The architecture supports both and may hybridize in the future.


📡 Planned Enhancements

  • Cross-worker message bus for intermodule sync
  • Priority task queue (e.g., user-triggered vs passive)
  • Persistence layer interface (write-through to Dexie)
  • WebSocket support for realtime corp log ingestion

📌 Summary

  • Background workers make the app feel fast and responsive
  • Work is divided across logical domains (market, API, fleet, scan)
  • Message-passing ensures clean separation and modularity