jtremback
commented
10 years ago Yea.. I've definitely thought about this.
The 3rd party wallet API (cryptos.io) should handle the 'real' transactions having to do with updating the balance of 2 accounts at once. It's being developed by some friends of mine, and I trust them to do a good job, as they are experts at this and it is actually the same backend as an exchange they are building. They take a transaction id with every call that can be used to look it up and confirm it after the fact.
Sorry there's no documentation etc for the API, I can see how that could seem somewhat shady, but they haven't had the chance to build a marketing site yet.
Once the real transactions are taken care of, the only failure mode is if one on the systems crashes while a request is airborn. In app/models/tips.js (in the frontend-api-foundation branch), I am recording the state of a tip before and after every call. This way, failed calls will be easy to find in the db and can be automatically resolved.
Even if we move away from using the Cryptos API (we should, later), I would still like to keep the wallet system and the tip app separated, for modularity, and so that other people can easily build on top of the wallet system without getting a raft of application-specific stuff to deal with.
At the same time, you make a good point, and I can't really argue against it. The Mongo DB models are almost done, and I say we keep using them for now, and have a Postgres integration as a priority.
I will note that I would prefer not to use a ORM for SQL, as the node.js SQL ORMs are IMO not great. Sequelize is bloated and I doubt it will save us much work, and bookshelf.js is based on promises (yuck) and Backbone (yuck yuck).
node-postgres is a good driver, although we will have to handle schemas and write SQL ourselves. I think we should be able to switch the DB and the models without changing any of the other application code.
Let me know what you think.
After some research into this kind of project, I think it'd be a much wiser and safer choice to go with an ACID compliant DBMS, rather than Mongo.
When it comes to finances and real money, you want everything to be perfect. Even a tiny glitch can cause confusion in the internal accounting, or in the worst case: lose a lot people a lot of money.
Is that an option for you? I don't think this will work or be as successful as it could be if there are some wrong design choices right at the start, such as the DBMS.