There are differences between Object storage and databases, with each catering to different needs. Object storage is generally used for data that doesn’t change frequently and doesn’t need to be accessed and processed heavily on an ongoing basis. For databases, it’s the other way around. So if ACID transactions are required, a database is the assumed choice of technology.
Is MongoDB marketed as an object storage technology? Is it suited to store large binary files (including video and audio)? In Meteor it’s used more as a database for quick and frequent reading and writing of structured data.
Services like Object Storage or Amazon S3 (the world’s largest object storage system) may be more suited for storing large binary files.
When even in the view layer simple arithmetic is inaccurate, it’s a problem. e.g. A common task is to check whether a result of a calculation is 0. Rewriting the example comparison I mentioned before, the result of
0.1 + 0.2 - 0.3 === 0 is
false, when just about anyone would intuitively expect it to be
true, especially considering that computers are perceived to be highly precise. Imagine how a user feels when she is told that she has not paid enough for something when the numbers clearly show that she already has. Sure, there are ways to work around this problem as mentioned before, but it takes extra effort which shouldn’t be needed in this day and age. BigDecimal and decimal have been around for around a decade in the other languages. It would have been good if MDG came up with an official solution in Meteor to this primitive problem to save developers’ time.
Meteor does not need to be “a financial transaction system”, but any improvements made towards becoming one would improve all apps as well as the marketability of Meteor, including to the corporate world.