It uses the CLI to connect to the database. When you start the tool, it creates a server on your localhost (localhost:4466), and acts as:
- Local database: it stores some stuff locally, like saved queries or DB configurations
- Query runner: when you run a query in the webapp it will call your localhost server, which will connect to the database and execute the SQL statement
It is technically possible to host it elsewhere, but I wouldn't recommend it (there is no documentation).
Your instructions say to go to https://app.dataramen.xyz/, which definitely isn't the locally hosted server. You might want to change that (and disclose if the local server makes data available to websites outside localhost, which the current instructions seem to imply)
Yeah, the entire presentation is a mess, I should've worked more on this side.
I see your concern about running it locally and then visiting a remotely hosted webapp. The way it works is that app.dataramen.xyz will call a localhost server (running on your machine, there is no remote code executed) to connect to the database. So all the data stay on your local machine, plus some webapp stuff stored in browser localstorage.
I went for this setup for essentially 2 reasons:
- I didn't want to ship webapp as part of the CLI tool due to the webapp size (it uses React, so the bundle is 800kb or so, while the entire local server code is 45kb).
- In the long term I want the users being able to connect to multiple servers from one webapp. For example you may have a local server running to interact with your local DB, but at the same time you might have configured a remote self hosted server within your company VPN.
It is a weird setup, but you end up doing weird things when you run an app on $0.00 budget
If the CLI allows your domain to connect to it and do arbitrary DB queries, it's definitely not something I could trust. Even if I knew you to be perfectly respectable, your hosting could get hacked and then there would be a pipeline for an attacker to my DB.
It's a reasonable way to do some things, but I definitely feel this cannot be called local-first, since it explicitly allows and expects external domains to connect to it.
The bundle size is no issue whatsoever for a cli tool for devs, it's only really a problem when serving via the internet.
Makes sense. Following all the feedback in this post I will have to make a lot of changes, I will also think on this one. But you are probably right, incorporating the app as part of the CLI might make sense.
I have a question: assume I moved the webapp into the CLI (so now everything is localhost), would you prefer using a CLI + webapp or an actual app you have to install (no more CLI, you open the app and do your stuff)?
I think for me, either would work but in different contexts:
- as an npm package for convenience for a node project, so i can just add an npm script to launch it on a local db
- for more general personal use, a flatpak-distributed app would be preferred (installing npm packages globally is a hassle)
I would want the source to be open for either case though (like others have mentioned too).
Before I posted this, opensourcing this tool was something I would do in the far future. However, based on all the different threads, it is clear that in order to gain some trust I have to go opensource sooner rather than later.
