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.
For what it’s worth: In the company I work for, Meteor is being used in a product for control rooms of nuclear reactors (!), (air) traffic control, news stations etc. So it sounds quite convincing if you say Meteor is being used in nuclear power plants
But in all seriousness, I think the graphql integration is pretty important for corporate adoption. Not only because it enables other types of databases (old-fashioned SQL, you know), but also because big companies tend to want to limit the amount of technologies they use (since they want to shuffle employees around, organize trainings, etc). The new data layer seems to work towards that goal by making Meteor suitable for a larger number of applications.
I’m extracting SAP data on (almost) daily basis with node-sapnwrfc and inserting it into MSSQL with seriate.
About a year ago I started with meteorhacks:npm and node-rfc on linux. After I got async (fibers) stuff done right all went fine. Moreover, fibers became my favourite pattern of writing async code.
Currently I’m about to extract data from approx 200 QuickBooks files using ODBC into Mongo and map/reduce it to MSSQL for use in proprietary accounting software. It will be a Meteor app.
There is an excellent talk about development of “line of business” applications which I believe the way to make corporate IT life much more meaningful than just restarting Outlook every time it hangs or not synching emails.
So, if you (or someone else) need help with in-corporating Meteor give me a call
