foxleigh81
commented
4 years ago There will probably be a more elegant solution rather than two entry points to the app. This feels like something we should be able to achieve with mocking/stubbing data.
Open IanMayo opened 4 years ago
foxleigh81
commented
4 years ago There will probably be a more elegant solution rather than two entry points to the app. This feels like something we should be able to achieve with mocking/stubbing data.
IanMayo
commented
4 years ago Here's a reference for hosting an application purely in the browser: https://en.wikiversity.org/wiki/WebApps_with_LocalStorage_and_AppCache
User stories
As a maintainer I wish to be able to use an in-browser database so that I can run e2e tests without network fragility
As a potential user I wish to be able to use an in-browser database so that I can investigate Serge without need to run any server application.
As a product owner I wish to be able to use an in-browser database so that I can provide a demo instance of Serge via static hosting (such as GitHub pages)
As a developer I wish to be able to use an in-browser database so that I can be develop using a simpler infrastructure
Description
In it's earliest technical demonstrator versions, Serge used an in-browser database. But, we moved it into Node to allow multi-user access.
The node-based implementation is certainly going to continue to be our main storage in the future, but there are scenarios (above) where it would be useful to have a browser-based instance.
It's probably sufficient for the selection of local or remote database to happen at compile time (expressed in code). I guess we would have twin
index_remote.jsxandindex_local.jsxfiles.Testing
inspectfor a running instance of serge demonstrates that it isn't making remote database calls, and the local storage shows one or more wargames (plus templates, etc).