This is is the world as it might have been, before certain unenlightened beings at Mozilla and MS decided peremptorily that developers should not be allowed to run SQL and persist large amounts of data via their browsers.
Well, the domain Webquery.org is still available! Maybe a few developers who have had enough of the npm / node / SQLite3 nonsense can band together and convince Opera to start a W3C revolution.
Meanwhile, click on the image to run the pen, then read the sad history of how SQL was killed during the browser wars here. The link and example code (that I modified slightly, since the original console bit didn’t work properly, and I am not sure if this is because the spec has been unsupported for a decade) were written by the brilliant Nolan Lawson. Make sure you’re using Opera before heading to my Codepen.
See how simple and intuitive this all could have been?
Imagine wrapping all the WebSQL async callback funy business in JS functions and exposing only a simple-to-use SQL API to the data analyst, who would be able to use parameterized SQL on the fly, querying data on their local machine, without worrying about getting trapped in the land of a million parentheses — the way it was before the Web mutilated SQL!
“Web Query” is exactly how I would have liked to implement StoreBoss.
No dance of a zillion nested parentheses and brackets.
Just vanilla JS and pure SQL in its original elegant nobility, with disk space on my comp where I securely encrypt my data and restrict access to it via icalcs.
I’ll have to try out the Dexie wrapper and see if I can up with something workable, using the brain-damaged IndexedDB. I have some ideas already in that regard.
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,
So here’s the latest on my plan to come up with the easiest, simplest way to write an intuitive, nice looking Woo-related browser app that’s able to connect in a very simple way to a local datastore on the desktop.
There is only one problem: unlike, say, C, JS has no built-in file I/O capabilities.
In the case of wanting to access SQLite, you have to use SQLite3 + node + npm, All this to accomplish what can be done in one line of code in C or a C++ program that uses ODBC to connect to SQL Server.
And if you ever had to write a JS script that uses SQLite3, you will soon begin to rue the absolutely maddening error-prone tedium of the unnecessary complexities of error handling when using SQLite3.
All I want to be able to tell JS to (1) connect to SQLite then (2) open a DB then (3) retrieve data from a table.
This is not exactly rocket science. I don’t think the user would mind waiting for a split second while a few hundred rows are retrieved in blocking, synchronous mode.
Instead of just being able to connect to SQLite synchronously, as you would if you were writing your app in C, you’re forced to deal with SQLite3 + node.js + npm in order to access SQLite.
Adding all these massive dependencies (over which you have little control, results in a situation where you have no idea what is really going on on your machine behind the scenes): massive security hole, obviously.
Why on earth was SQLite3 not built to also support synchronous I/O?
After all, remember the SQLite mantra: “open-source, zero-configuration, self-contained, stand-alone… ” etc etc?
And remember, too, that the intended number of simultaneous end users is exactly 1. In this scenario, it is RIDICULOUS to be forced to make asynchronous calls to a local db.
Plus which, when it comes to SQLite3, does it ever mentioned (gulp)
in the documentation? Well, does it, punk?
This NJS (NPM + JS + SQLITE3) Rube Golberg jive is the antithesis of that stated SQLite ideal, or am I wrong?
Then, I thought… why not ODBC?
For a moment, I allowed myself to fondly remember those MS Access days wayback in the 90s when I was able to use ADO to grab data from almost any source, no fuss, no muss, and thank you very much.
My mood began to turn increasingly dark, at the unfairness of Life, as I googled frantically. Then, the clouds parted, and I found… this.
I found it!
An ODBC driver that’s MIT licensed and recommended by no less a reputable source than Microsoft.
I quickly added it to my ODBC data sources in the Administrative Tools of the Control Panel in Windows.
Then I tested it with Libre Base. It worked, with some minor fiddling (see below), like a charm.
Then I tested it again, this time with Microsoft Power BI (which I noticed, by the way, is developing connectivity to Stripe as a data source).
That worked fine, also.
So the driver ran as advertised.
But I was not out of the woods yet.
So all I had to do now is figure out how to get my JS StoreBoss DB function library to work like this.
Now that is what I call beautiful. Except that it turned out to be a really bad idea (see Postword below).
Postword: After installing this complex JS chromium runtime extension (which requires you to use an elevated Admin CLI), I could not get the example code to work, and left a call for help in its git page. I say bag this native extension stuff; too much of a headache. But if you can follow what Gabriel Schulhof says about native add-ons in this YouTube bid, please leave a comment!
UPDATE #2: Hello, hello. What’s this? Let’s first look at the Trouble Shooting guide. On Windows, as opposed to UNIX derivatives, things are more complicated (as always). Let’s see… hmmm.
Start an Admin PowerShell: Right-click the start icon, then pick Windows PowerShell (Admin)
Install both vs2015 and vs2017 libraries. Each line will take ~5-10 minutes.
That is what I had to with the native extension, and it trashed my setup. I’ll not be installing anything again that forces me to use Admin privileges, so bag that. Too dangerous, and what if an end-user has to change his or her machine’s configuration to get this package to run? StoreBoss would be dead in the water. Troubling issues page, too.
Okay… so it’s just a PHP file with header info, for now, but I think it looks right at home in WP admin.
I did some more data modeling and source data checking today to make sure that the “tick-and-tie” algorithm will work, given the test source data available from WC, Stripe, and Bank of America.
Much of my day was spent wrestling with the question as to whether I should implement part of StoreBoss on a desktop. I discounted MS Access and/or Libre Base as unsatisfactory options for a variety of technical and functional reasons.
So what other choices do I have?
For example, if I use SQLite as the DB engine, what language should I use for the GUI part?
Python has been all the rage for data analysis for some time, so Python/SQLite is an obvious choice.
I don’t know Python;
I don’t really want to hassle with Tk or other Python frameworks to produce a desktop GUI that will probably look amateurish;
I don’t care for some of the limitations of SQLite.
On the other hand…
I am stunned — stunned! — at what PHP programmers have to go through if they wish to debug their apps by stepping through code; and;
I want to avoid, as much as possible, being overly ensnared by the WP way of doing things;
You can do a lot of cool thing in terms of data visualization with existing JS libraries.
So it looks like the split might be SQL + basic PHP for extracting and prepping WC data for querying by parameterized stored procedures on the prod WP server. By focusing on doing much of this work via SQL, I can quickly create a few custom tables in WP, populate these via SQL, while providing value add transactional information via a bare-bones PHP script that (safely) calls the queries, then display results using JS razzmatazz.
StoreBoss would also provide a download facility to either a JS/SQLite SPA app (again, this is a lot of work for one person, especially for someone who is more of a data modeler/architect than a down-in-the-trenches developer who eats Laravel magical callbacks for breakfast) or EasyMorph (a bit on the expensive side, but fits right into the code-free data analysis mantra) or MS Power BI (more achievable, in a shorter time frame, with fewer GUI headaches, despite the learning curve) for sophisticated data analytics on the desktop.
This type of hybrid architecture is a simpler cousin to the sort of Big Data deployments ably discussed by Lockwood Lyon here.
The “Actions for REST APIs” might allow for downloading of data from WC’s headless interface. The ability to pipeline data to Power BI in December ’19 is pretty exciting too — although its (meaning Power BI’s) notions of what constitutes a DSS data store and its associated BASE standards compliance requires further investigation, ditto the pros and cons of time spent mastering non-portable, non-transferable MS data manipulation sub-languages.
We’ll get to all that down the road. But for now, plain ol’ StoreBoss will live in the open-source WP cloud.
Initially, users will have to manually upload their bank file transaction data, and that’s a drag.
But that’s how it has to be, at least for now.
B of A (which is the bank I use for the e-commerce site I run) would not accept a wildcard SSL certificate comparable to the one used by SiteGround for my site: so I would not be able to programmatically access B of A’s CashPro Account Info API from my hosted SG server.
I’ll have to figure out how to make the uploading (of banking data) to StoreBoss’s staging table as simple as possible; there might be existing, open-source software out there that might be of help in that regard.
Maybe I can just lay out a sample Libre Calc template and my prospective customers can do the work of mapping CSV fields to the DB columns. If explained clearly, and it’s not too complicated a file structure, the payoff might be worth the tedious hassle. But I don’t like this part of the solution… so we shall see how all this pans out. At the very least, I should be able to develop reusable template mappings for the top 3 US bank transactional files, and have those available out of the box.
Speaking of reusability, one of the interesting things (to me, at least) of this proposed StoreBoss architecture is that almost none of the code touches or relies on WP core. What this means is that I can use JS libraries such as Datatables (which in turn depend on JQuery) that will greatly reduce the coding I have to come up with attractive tables for StoreBoss, and even if I end using other libraries (say for charting or date-fns for temporal calculations) that carry MIT licensing, it won’t matter, since I’m hitting the database the directly, and not depending directly on WP/ WC. I will have to verify this with plug-in gods at WP, but I think I’m right. Why re-invent the wheel?
Meanwhile, I am close to finalizing the sb_transaction_event table, and ran a few test analytics SQL queries against real-world data.
Boy was I unpleasantly surprised at some of the things I found! (Hint: certain online CC processors appear to charge over 3% in some cases, which I think is pretty rich, considering that my client’s in-store credit card processor charges less than 2).
StoreBoss can’t come soon enough.
It shouldn’t be only big corporations that can shell out for automated systems that check this sort of thing.
What about the SMB WooCommerce store owner who can’t afford fancy cloud-based systems and an army of accountants and data analysts?
If smaller scale WC store owners are doing any kind of volume, you can bet there’s money probably slipping through the cracks. And even if there isn’t, would it be nice to know for sure?
I’ve spent the last month coding in Florida, where the “local” Burmese python population is apparently exploding.
I was putting together an app that used PHP, HTML, CSS, some JS, and a custom SVG ico. It currently runs on a desktop Xampp server configuration, with MariaDB 10.3 as the storage engine.
Initially, I thought I would eventually turn this application in a WP plug-in, but have since changed my mind. The more I got my hands dirty with PHP and Maria, the less enthusiasitic I became about this whole plug-in idea.
Instead, I realized that my app would best be implemented as a series of “widgets” written in Python, with SQLite as the data store, and PYSimpleGUI on the front end.
Going Xampp was hardly a waste of time though. But rather than have my Data Analysis/DSS app hit the WP DB in real time, I’ll create a simple WP helper plugin that downloads the STRIPE and Woo Order info that’s needed by my app . Instead of using plain old CSV, I’m thinking of implementing a micromodel download, as described here. Not sure yet how this would work, but the concept of dowloading relations (in a Coddian sense) instead of data cell arrays sounds far more appealing.
Using DB Browser for now, to look at my test data, and play around with SQLite, until I learn Python well enough to write the actual app.
SQLite seems perfect for my application, which is meant to be used by a single user — whom I envision to be a non technical business owner running a small online and/or brick-and-mortar shop.
Since the app deals with sensitive financial data, it’s actually best — from a peace of mind standpoint — for the data to live securely where no one (presumably) can get at it but its one legitimate user — the store owner who is looking at store cash flow information.
What a relief not to have to write the contorted sanitizing code in order to deal with SQL injections and other annoyances!
However, I still have to look into the RCE vulnerability in SQLite that was identified earlier this year.
So far, though, SQLite seems to be lightning fast, espeically given the small test sample I am using (around 400 rows). There are peculiaritiies in syntax that I have to study; a good primer on this topic can be found here. Another peculiarity is that atypical code of conductmanifesto that made the news recently; and that is all I will say about that!
My work is cut out for me. I have to simultaneously learn Python 3.7, PYSimple, and how to use GitLab — not to mention figure out the algorithms for my app.
I hope to resurface in Pythonesque mode in a month or two or three.