My sympathy. Spent much of a day debugging a C program, had to go so far as looking at its assembler language intermediate output before I noticed something funny... which was the result of an extra semicolon I'd been staring at all day and not noticing.

The longer you're in the business, the less that sort of thing surprises you.

No, it isn't ACID compliant.

You can get around some of that by, say, putting all your database changes into a linear logfile, and writing a checkpoint record every now and then when you know the database is consistent. If something bad happens you can back up to that last checkpoint and re-apply those changes. That gets you "D", durability.

But the "A" and "I" require transactions of the type which can be rolled back. You can get the "A" and the "I", atomicity and isolation, by committing those changes to Mongo in complete chunks, e.g. a transaction which requires 100 changes to the database gets shoved into the logfile and the changes executed all in one go.

As for the "C", consistency, that depends on your definition of "consistent". You'll get some of that in Mongo, DB structural consistency, but things like balances on a customer record being consistent with its debits and credits? In just about any situation you're on your own for stuff like that.

If you're going to be doing accounting and inventory for 100,000,000 entities, maybe it's worth the trouble. Or as an academic exercise. But you're tolerating a lot of maintenance headaches, for a SMB system, in exchange for not paying AWS for a bunch of VMs with MySQL on them.

While I agree with the basic premise, when I see the words "Pain points of Node.js" here is how I react:

A) Node.js provides a means of writing back-end logic in Javascript. Who in his right mind would want to do that, when appropriate, i.e. non-scripting, higher-performance, languages are available for the task?

B) The term "pain point" seems to be a favorite among seagulls: usually consultants, who swoop in, makes noise, crap on everyone, and leave. We do already have a word for that: they're "problems".

Needs to run headless, as it requires two manual steps, logging in and launching it, every time the machine which hosts it is re-started. Why retain two points of failure? They've had no complaints about it because people there are accustomed to it being wrong, i.e. to having to have a person in the loop for it to operate properly.

For Android and WinCE (or whatever Ms' handset OS is called these days) it will be more of a matter of learning the OS' programming interface than of writing code.

All allow the network stack to be wedged, so it's a matter of counting bytes in and out, storing the count periodically and whenever the app receives a shutdown event. That will be the difficult part: not difficult to code but difficult climbing a steep learning curve.

Creating a rudimentary UI to show the results is the simple part.

There are any number of free Android IDEs out there, and you can get VS Express from Microsoft to code for their handset OS for free (the last time I checked) from their Web site.

Worked as an independent programming contractor for about three decades, doing various sorts of systems, anything from accounting to programming tools, in maybe twenty languages. It pays well but the work is intermittent, and requires a good social network. It's got rough ten, fifteen years ago when contract agencies decided the only way to grow in a saturated market was to run the independents out of business. I held out for a few more years, then went corporate, but there are still a good many niches where an independent can thrive, most notably in handset / tablet software.

Do you have an Android handset? Download the Android Studio IDE and start writing code. It's a useful skill, and in demand at the moment. Learning Java is the hard part. You've done that.