Sales Reporting App: thoughts and opinions.
Naturally, when beginning to stub out any new project, we usually come from a place of familiarity. That being said, while I couldn’t say most other stacks would not fit this project, I’d go with Node.js on the backend, with React.js in the browser. Probably partiality on my part, but one of the larger advantages of any stack for a given developer, is how quickly they can get up and running with it.
For React though, it has a good thing going for it, in that it also works on native mobile. This certainly couldn't hurt, while opening the door on growth into other platforms. Because it’s a pretty straight forward transition, between React and React Native code, developers not even familiar with native could get things done with the same basic principles at hand. This means you have more room to up-sell and enhance the project in a meaningful way, with the same team.
As for the database. I would tempted to say a NOSQL, for instance MongoDB, would be an excellent choice. However this project strikes me as one that would scale pretty fast once live, and that said I bet relational database would start to look like a better option at time went on. So, for purpose of future-proofing I would be starting up with something like Postgres. It may take a tad more to get up and running, familiarize, etc but it’s well worth it to avoid a mass data migration that could very well be inevitable.
For crunching CSV's, generally speaking I would experiment with whatever NPM packages were would there, preferably one that converts the file into JSON format. It would be advantageous because, more often than not, DB interactions happen in JSON and what can pass straight through to data storage, should. Generally we want to keep pre-processing of the data to an absolute minimum, aside from sanitation of course, we'll want to dump it on the DB and produce insights from the full set instead.
For the generation of reports, in order to keep it snappy and scalable it's not so much about smart querying as it is smart caching. It is very important to periodically, or even in some cases in-realtime, generate oft-accessed computed data and store those along with the full dataset itself. That can be as simple as regularly updating totals during off-peak hours, to streaming incoming data into event buffers which only later will mutate any application state in a digestion phase. I could go on and on about this, but long story short: storing one extra datapoint is almost always cheaper than querying large chunks of your dataset for at-a-glance insights. On top of that, a hot cache can also be helpful. If it’s warranted, having a datastore or NOSQL service collecting more recent data will allow for both storing data that can become stale. Keep real database for information you intend to keep long term.
For retrieval, I could go a few directions with this, but mostly it goes like this. If the client may retrieve data, the client should retrieve data. This tends to be more true for native apps and other secure contexts, but it’s good to avoid copy-passing. A server and its API is best leveraged to act-upon, reorganise and compute data, not retrieve DB entries, at least as much as that can be avoided. Whenever I make any react app I always write an agent, a singleton class that exports one instance in local state. That can be defined with any number of straight forward abstractions, so it’s a simple matter of MVC just asking for information and waiting on an already collated response.
For permissions, depending on the application and style of access I would use anything from tokens (especially if DB solution supported that) to some form of crypto-at-rest, if I was really paranoid. It depends on the situation really and what matters to the customer. For enforcement of transaction (no fraudulent data slipping in) a block-chain can be a great tool. It's not just for widely distrobuted ledgers, you can use it to simply ensure data can never be corrupted (because checksums would fail).
Hosting though, oooh goodness, is a tossup and a half. However, my MAIN concern is how much of the entire app I might get under one roof. My favourite host lately has been Zeit Now. They don't offer inexpensive object storage though, or DB management which is a bummer. However, if we were happy with a bit of separation between client layers, API, and storage, I’d still consider them. They have neat features such as ⚡️ full CLI support ✨ letting manage, deploy and pretty much anything I'd want to do via command line. If it doesn't sound cool, it's a lot cooler than it sounds.
AWS, Azure, and Google are significant platforms, but all have certainly their quirks, their costs and walled gardens to an extent. I used to think cloud was a no brainer, but experience has taught me to shop around a bit.
Certainly stack selection is a big process, not to take lightly. It’s certainly a decision though that benefits the most from debate, I'd say.