I spent this morning exploring available tech to address this goal:

Add a bigdata database to my application, to archive older data out of the realtime local model

This is for my stock app, which deals with realtime in-memory data during market hours, with a delayed-write to local storage.  At the end of the day, it can then archive most of the data collected during market hours.

Because I have not achieved “success” in life yet, at least enough to allow me to pursue my larger goals uninhibited, I have to be very careful about how I apply my limited resources.  To be more precise:

  • Follow patterns that are as simple as possible (but no less), and sustainable into the next decade.
  • For my projects, limit languages, libraries and tools to those that are
    • well maintained
    • solve difficult problems more elegantly than I could solve with a medium level of effort

The result of today’s philosophically-informed research:

  • The primary languages of my software projects should be Javascript and C++
  • All data should be defined by JSON schema that is used to generate code, via quicktype
  • Long-term libraries and tools include boost, jquery, bootstrap, accounting.js, moment.js, nlohmann::json, sqlite, postgres

Note that using quicktype with nlohmann::json is an elegant way to effectively get C++ reflection.  Once you serialize an object to JSON you can walk all its fields.  Then you can do things like automatically build SQL queries for your classes based on the JSON schema.  Beautiful.

PS. I avoided spotify-json, StaticJson/autojsoncxx, Google Prototype Buffers, Code Synthesis’s ODB, the sqlite JSON1 Extension, C++ reflection libraries like RTTR, lots of code from Stiffstream and Chilkat, etc. because while they are all brilliant and compelling, they bring extra weight.  The world keeps churning though, so keep searching.  Also, there are cases where my choices do not fit, most obviously being cross-platform mobile apps, which will have to be saved for another post… 🙂

When NPM gets bumped, you start with an empty module cache.  To restore it with optimal dependencies:

cd baseapp && rm -rf node_modules && npm -g install
cd dependentapp && rm -rf node_modules && npm -g install
cd thirdlevelapp && rm -rf node_modules && npm -g install

 

My headaches described below were due to my npm module’s dependency clauses’ versioning stanzas. I had set dependencies to automatically update but clipped them to the current minor version. Eventually they got crusty, and npm actually stopped finding the versions I was demanding in a speedy fashion. Both edges of the upgrade knife can cut you, don’t let dependencies get too old. 🙂 Fuller explanation on SO.

Historical blathering follows… (continued…)

Five minutes into this javascript exploit video, you’ll understand why that massive stack of node modules in your app is BAD.  Nicely done.

And… 14 minutes in and he hits Moment.js… which is everywhere… with a straightforward tough-to-solve regex DDOS hack.

Then mongoose… then…

Diamond dependencies are everywhere, from dll dependency hell to running an upgradable linux distro to your node stack to figuring out your #include order.  Check out Titus’s perspective, it’s pretty tight.