No description
The reason for isolating the trader class is testability. It's hard to properly test code with as much global state as files in `lib/api` had. With a `Trader` class we can easily instantiate multiple objects, with different configs, without the need for seeding the database with test configs, effectively enabling us to do unit tests as well as integration tests. Besides that, this will allow easier reconfiguration, thanks to `Trader#configure` method. |
||
|---|---|---|
| bin | ||
| lib | ||
| test | ||
| testkeys | ||
| .gitignore | ||
| .jshintrc | ||
| package.json | ||
| Procfile | ||
| README.md | ||
| UNLICENSE | ||
lamassu-server
Lamassu remote server.
Installation
git clone git@github.com:lamassu/lamassu-server.git
cd lamassu-server
npm install
If you're working on this stack, you probably want to npm link
lamassu-atm-protocol.
git clone git@github.com:lamassu/lamassu-atm-protocol.git
cd lamassu-atm-protocol
npm install
npm link
# Back in lamassu-server
npm link lamassu-atm-protocol
Running
node lib/app.js --https
The https flag is required for local testing. When deployed to a PAAS environment - such as heroku, the https flag is not required, as the SSL connection typically terminates on the load balancer and the application will see http only.
Deployment
Deployment of this application is described in
lamassu-admin documentation.