Jrfs critique request

[waynesbrain]

Hello. I saw your post about GlassDB on Hacker News today. I think you are probably a much more educated programmer than I am, so I was wondering if you would give a critique or any feedback of my work at https://github.com/jrfso/jrfs

It’s a database-like file access system. I also could not find anything nearly similar to what I built there and it’s tangentially similar to what you have done.

If not, no biggie! Thanks for your article and sorry if this issue is the wrong way to contact you.

[mbrt]

Hi! I read through the README, and it's not clear to me what is the main purpose. I see many features, but they seem all slightly unrelated to each other. This is just from a superficial read, but I would recommend to:

• Do only one thing, and well. If there's space for more features, without bloating the project, they will come naturally from a well-designed base.
• Exposing unrestricted server side operations to client is problematic from a security perspective, but it seems you're just targeting the local machine?
• What is the main value proposition? You mention that it's for tools that need more than the standard browser File System API but less than a full-blown Electron/Chromium installation. I wonder what's wrong with having a full-blown installation. Perhaps you could elaborate on that?

[waynesbrain]

Thanks so much for you response! I appreciate your time and I'll try to keep my responses direct and to the point.

• The one thing that I want this library to do well is to give my local web client complete access to the host filesystem via my local devserver process in a way that allows both the server and client to conveniently interact with the JSON files as a database. I think that one-thingness is a very relative and contextual idea, but I did break the functionality of this library into 6 different packages in the @jrfs namespace: core, idb, node, typebox, web and ws.
  • However, I can also think of many popular libraries which (I think) do more than one thing well. I'm sure this is debatable, so I won't list any examples because I don't want to debate one-thingness.
• Yes, this would be extremely insecure if exposed to the Internet in it's current form with no security measures. I am building it only for a localhost devserver which might be installed via NPM as a dependency or a standalone package. I'm also considering to create a similar backend in Golang. However, I do believe that any level of access can still be secured. (Example: Supabase - my frontend client code can make direct calls right into Postgres via that system and that is widely used.)
• The main value proposition for me is to let my frontend designer tools implement most of the logic without requiring another instance of Chromium to run or be installed. I would prefer to use either my main/dedicated browser process to run things and while I cannot provide any evidence that lots of people feel this way, I think just searching for the word Electron on site:ycombinator.com would suffice to see that it's a fairly wide complaint in the programmer world.

If I used Electron I would have some privileged JavaScript code running on the Node side of things and my unprivileged frontend JavaScript code would send the Node side some messages to do privileged stuff. That's the same setup that I'm offering with JrFS, but without Electron (and only for filesystem related stuff).

[mbrt]

Gotcha. I can see how this can be useful, however it doesn't seem to relate to what I'm doing with glassdb? It's a key value store on top of object storage, there's no frontend or local file system involved, so it is quite a different goal.