Precog currently uses MongoDB to persist metadata, such as account information, security information, and so forth. MongoDB is a database in its own right, which has to be installed and maintained. This takes a lot of time and domain knowledge.
In order to minimize the moving pieces in Precog, remove a point of failure, and simplify both initial installation of Precog and ongoing maintenance, the dependency on MongoDB needs to be completely eliminated.
We need to swap out MongoDB with a robust, pure Java embedded database (such as H2), which will make it easier to allow users to introduce redundancy in the future (by switching to a distributed SQL database).
The main criteria is that whatever we use to replace MongoDB should not require installation or maintenance of any kind; it needs to be idiot-proof, crash-proof (auto-recovery), and configuration-free.
Per @nuttycom, the main touch point in the code for the security service is ApiKeyFinder (what about for the accounts service?). The trickier bit will be refactoring and dead code elimination in the dvergr service.
Precog currently uses MongoDB to persist metadata, such as account information, security information, and so forth. MongoDB is a database in its own right, which has to be installed and maintained. This takes a lot of time and domain knowledge.
In order to minimize the moving pieces in Precog, remove a point of failure, and simplify both initial installation of Precog and ongoing maintenance, the dependency on MongoDB needs to be completely eliminated.
We need to swap out MongoDB with a robust, pure Java embedded database (such as H2), which will make it easier to allow users to introduce redundancy in the future (by switching to a distributed SQL database).
The main criteria is that whatever we use to replace MongoDB should not require installation or maintenance of any kind; it needs to be idiot-proof, crash-proof (auto-recovery), and configuration-free.
Per @nuttycom, the main touch point in the code for the security service is ApiKeyFinder (what about for the accounts service?). The trickier bit will be refactoring and dead code elimination in the dvergr service.