The idea for the Watermelon architecture is to be database-agnostic.
Watermelon is a cross-platform high-level layer for dealing with data, but can be plugged in to any underlying database, depending on platform needs.
Think of it this way:
- Collection/Model/Query is the reactive layer
DatabaseAdapteris the imperative layer
The adapter merely performs simple CRUD (create/read/update/delete) operations.
DatabaseAdapter is a Flow interface. Watermelon comes with two concrete implementations:
SQLiteAdapter is an adapter for React Native, based on SQLite:
- Queries are converted to SQL on app thread using
- Communication happens over
NativeModuleswith a native-side bridge
- Native database handling happens on a separate thread
DatabaseBridgeis the React Native bridge stub
DatabaseDriverimplements Watermelon-specific logic (caching, etc.)
Databaseis a simple SQLite abstraction layer (over FMDB on iOS and built-in
LokiJSAdapter is an adapter for the web, based around LokiJS:
- Why LokiJS? WebSQL would be a perfect fit for Watermelon, but sadly is a dead API, so we must use IndexedDB, but it's too low-level. LokiJS implements a fast querying API on top of IndexedDB.
LokiJSAdapterdelegates everything to a separate thread over
WorkerBridgespins up a worker thread running
LokiWorkermaintains a queue of operations and executes them on
LokiExecutoractually implements the Adapter operations
QueryDescriptionobjects to Loki query objects
executeQueryimplements join queries (
Q.on), which Loki does not support
If you want to write a new adapter, please contact @radex for more information.
⚠️ TODO: This section needs more concrete tips