Ask HN: GUI approach for client-side CRUD to edit data model used by devs

1 points by nuclx 8y ago ↗ HN

I'm working on a code generator for a C library, which generates .c and .h files holding structs, tables and types from an easily managable data model. At the moment devs use a Flask web interface to update the data model, which is stored in an SQL db. The C code can be downloaded from the server by HTTP-fetching a zip file. This works ok-ish, but using an SQL db feels overengineered for the use-case (the data is just in the order of 100s of kilobytes) and in my opinion the data model should be under version control.

I think JSON would be an easy to work with format for the data model. Since the data model is somewhat complex (e.g. it contains non-trivial relations), I'd like to provide a GUI to edit it - basically a CRUD, which transforms a JSON.

One idea is to run the whole CRUD in-browser but offline (à la MyEtherwallet), i.e. provide the app as index.html and .js files to users. A problem is file-io: The JSON model would have to be loaded into a React browser app using a input-file dialog. Afterwards the updated JSON would have to be downloaded and copied over the previous version of the JSON. The upside is that it 'just runs'. No node.js installation or anything needed on developer systems. The downside is, that it can be unintuitive to use, e.g. the application state is lost, when the user hits F5 or the back-button.

An alternative to a browser app would be to use Electron, but the overhead of the binary version is a bit frightening due to embedded chrome/nodejs. Open question (I should try that out): Is it possible to commit the binaries once, such that users just have to update the webapp part (html+js) from version control subsequently to get an up-to-date app?

Are there alternative approaches that I'm missing?

TLDR: Need a versionable GUI approach to transform a JSON document, which is readily runnable after syncing the GUI source and JSON-file from version control. Completely client-side, no setup-step or dependencies for users.

lioeters 8y ago ↗

I'm not familiar with the server-side stuff (Flask, C code generator - sounds interesting!) but had a couple thoughts on the web/client side.

JSON file(s) can be stored in the user's browser local storage, with IndexedDB [0].

The "open file" dialog can use `<input type="file">` [1] or the File API directly [2].

Using React router, history API and optionally Redux, application state can be maintained even when the user hits the back button [3]. It's somewhat time-consuming to figure out, but can be forgotten about once it's set up.

It seems all or most functions you need could be achieved in-browser.

As for Electron, the app size starts from around 120MB~. I'm also thinking about how to do minimal updates with a bundle of HTML/CSS/JS, or better yet, incremental diffs. I have a feeling that there are existing libraries that enable this, just need to figure out how to put them together, or find a project where someone has solved it already..

---

[0] https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_A...

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

[2] https://developer.mozilla.org/en-US/docs/Web/API/File/Using_...

[3] https://reacttraining.com/react-router/web/api/BrowserRouter

nuclx 8y ago ↗

Thanks for the pointers! Great to see someone actually understands my requirements.

I'm already using the <input type="file"> method to load a file into the app. For the saving/download part I tried dynamically generating the output JSON and putting it in the DOM [0], but I don't like that this method doesn't allow to open a Save As dialog with right click. Always rendering the link to the DOM as in [1] crippled the performance of my app, since the link got rerendered on each keypress.

Offline browser applications are definitely appealing, since they're so trivial to update. I think I will dig into LocalStorage, React Router - not sure if I really need IndexedDB, but it definitely sounds interesting too. What I'm missing is comprehensive literature or articles concerning this type of applications. They came to my attention through cryptocurrency websites like MyEtherwallet and EtherDelta.

[0] https://stackoverflow.com/a/18197341

[1] https://stackoverflow.com/a/3665147

lioeters 8y ago ↗

I've used a similar solution/workaround to create a data URL blob for saving files from a web app. I agree it's not ideal and quite limited. If it were an Electron app, there's an API for opening native file dialogs [0].

As for rendering an updated download link on every keypress - I remember I had to solve it by using a "dummy" download button: when it's clicked, it generates a fresh URL blob to replace the link href, then trigger another click event to start the download. I forget exactly how/if that worked.

A couple of months ago I came across remoteStorage, "an open protocol for per-user storage on the Web" [1]. I have not implemented it, but the main idea seems to be "offline-first" apps that keep the user's data local, then sync if/when online.

There's also "progressive web apps" [2], to promote this kind of offline-first approach and leveraging local storage.

[0] https://electronjs.org/docs/api/dialog

[1] https://remotestorage.io/

[2] https://developers.google.com/web/progressive-web-apps/

nuclx 8y ago ↗

I would love to see Chrome/Firefox embrace the unhosted approach a bit more, but security concerns are certainly a hindrance when it comes to empowering web apps.

[deleted] 8y ago ↗

(comment deleted)