What are the pros and cons of the two approaches outlined below?
I am in involved in a project where we essentially only need functionalities that could be accomplished with a classical desktop app. The user will input data, processing will occur, the app will give back results. The user will be performing discrete ‘analyses’ of data, and needs to be able to ‘save their work’ for each ‘analysis’ to a file that they can download and share. We could just write a desktop app. However, we are distributing commercially, and it’s a big headache to get desktop apps installed on corporate IT systems. Thus, solely because they require no installation, we need to write a web app.
We are discussing how to architect the app. I am an engineer, but not a software engineer, and am not deeply knowledgeable about web apps. I am somewhat mystified by the apparent complexity and redundancy of the conventional web app architecture. It seems to me that the ‘conventional’ web app architecture is needlessly complex and redundant, at least for our purposes. Could someone help explain the pros and cons of different possible approaches? Specifics are described below.
Our initial design is as follows. We have a database hosted on the server. For each discrete ‘analysis’ that the user performs, the user is inputting a variety of information into the app. There is a front-end running in the browser using a Javascript-based front-end framework. When users input information into the front-end, it posts the information to the server database. Users want to be able to import/export analyses between each other, back-up to their local system, etc., and so we have a functionality that writes and reads a json file from the database that encapsulates all the information in each ‘analysis’ that the user has performed. The data processing – the core functionality of the app – is done by a standalone, preexisting Python program that runs on the server. When it is run, the database uses the ‘export’ functionality to write the json file, and then that Python script reads it, and writes the information to an output file that is read back into the server-side database and then fed back to the front-end in the browser.
Here’s the question… for this specific application and use-case, what’s the point of posting each bit of information to a database on the server??? My understanding is that conventionally web-apps use a server-side database to keep track of information and use the front-end as a thin layer to communicate between that back-end and the user. This makes sense for most web app use cases, but why is would that be best for the use-case described above?
Everything that the user inputs must be stored in a Javascript variable in the browser as part of the front-end. And then, everything that the user inputs needs to be saved to a json file because (as noted above): (a) users need to be able to download the data in their analyses as part of an export/import capability, and (b) this is how information is provided to the back-end processing script. So, why wouldn’t we just write code in the Javascript front-end, have the Javascript code itself write the json file when needed, and not bother uploading the details of all that information to a server database? I don’t see why we’d spend effort mirroring the Javascript data structures on a server-side database, just so that IT can write the json file, instead of having the Javascript in the browser just directly write that file.
To enable the user to save data on the cloud between sessions, we could still use a database on the server, but it could be very simple. For each ‘analysis’ the user has performed, just store a bit of metadata (name, date created, etc.) and the json file generated by the front-end back-end.
It seems redundant that to have all these local Javascript front-end variables (which are numerous and in some cases are in semi-complex nested structures, such as tables of information), and then have to mirror all of that one-to-one in a detailed server-side database. Because when you really boil it down, the entire purpose of the web-app is just to take the user’s inputs and reduce them to a json file that can be written and read for import/export and for the back-end processing tool, and then read back the results of the processing and present the results to user in plots. I think this could just be done directly by the javascript in the browser.
I understand that it’s typical to use the browser front-end solely as a thin layer for communicating to/from the server-side database. But for this use-case described, why would we bother with this approach? Why not just use the browser itself to generate the json and not bother keeping track of the details of the (somewhat complicated) user-inputs in a server-side database? Except, as I said, for having a simple server-side database that saves users’ json files between sessions.