I spent the last week researching and testing out the various options I have available to build StoreBoss.
The use case of StoreBoss is Cash Balance Ledger accounting.
The idea is to combine data from WooCommerce, credit card processors like Stripe, and a store owner’s bank — in order to automatically verify an order’s processing flow.
Based on this information, StoreBoss can then provide a variety of temporally-based analytics — beyond the usual charts and graphs you see in many e-commerce db front end apps.
My goal is to develop unique and useful data visualization functionality — while ensuring that access to such information is no more difficult for a non-technical store owner than tapping a screen to wake up a smartphone.
My ace in the hole in all this was that I have rusty but still decent db skills– acquired through a career of working on trading systems on Wall Street. That’s pretty much it in terms of any ace-in-the-hole advantage!
During the past month, after prevaricating on the issue of PHP/WP admin screen vs some other implementation, I came to the conclusion that I wanted StoreBoss to be a single page app that primarily lives on the desktop.
After some debate regarding the suitability of Python for this project, I discarded that option in favor of a single language JS approach.
I took a week to learn enough about node.js and npm to be able to write a few simple scripts that access tables in a test SQLite database.
I also worked through my issues with callback hell, and ramped up from old school error handling –> to promises –> to async/await –> until I finally came across a really cool async utility that does the job of smoothing the pain through syntactic sugar.
I also surveyed the intimating and confusing JS framework landscape, and also took a long look at the development and evolution of node.js over the last 10 years, as well as its gradual intermarriage with npm.
I will be upfront about something.
I did not particularly like this.
It brought up all kinds of code ownership issues, those same ones that arise with MS-owned Github.
I also do not like how npm’s original developers and people who were crucial to its original development were ultimately screwed.
I was aghast at when Terminal ads began appearing. The idea that ads are bundled in packages smells to high rot.
As for node.js, it gave me pause to watch a tube vid featuring Ryan Dahl on the mistakes he made with node — which he, of course, invented, and left behind to build Deno.
I also am turned off by the massive code size that is apparently required to generate a simple “hello, world” executable using the npm/node duopoly — and intend to experiment with ES modules to see if I can do away with npm entirely.
I don’t want StoreBoss to turn into some 20 or 50 or 100MB Windows blotto .exe behemoth that a store owner must download and install on his or her machine.
But worse of it, Node is categorically and fundamentally insecure.
How do I get a StoreBoss end-user to trust this application if its runtime environment could allow, say, the theft of SSH keys on his or her machine?
Given the fact that, as CEEJ once said, if you’re using node, you’re using npm, and vice versa, what’s an alternative?
Given the issues surrounding the npm + js stack, can I simple ditch JS entirely?
Specifically, does Typescript support modules? Ans. from the documentation
What about the SQL3./node module? Is there a Deno equivalent?
And without a driver/binding from Deno to SQLite….
Okay… so even I have to stay with Node/JS, despite the issues, how do I get JS to render HTML/CSS without getting entangled in a Jurassic framework?
Well, I’m going to take the plunge and develop StoreBoss as a lightweight Vue.js 3.0 app.
As of this writing, Vue 3.0 is not yet officially released, and I have never actually used Vue.js — but the documentation, demos, YouTube talks, Medium articles, and programmer feedback on Vue are all consistently impressive.
This is not going to happen overnight.
In the meantime, over the next 20 days (before my Sigma trial expires), I am going to complete doing my study of Stripe’s schema. I am not just going to lift SIGMA’s table structures — what’s the fun in that? … but redesign them such as to be generalized, such as to also support, say, Paypal or even a B&M CC batch processor.
Then I will take a really big step, and write the JS needed to call the Stripe API in real-time,
Lots of work ahead.
I can’t wait to see the results!