Screenshots on the website would be very helpful. This sounds interesting, but would like to see what the actual UI is before setting anything up. It would also be good to link to the Github repo for the CLI part - I'm skeptical of giving an unknown tool access to my database without understanding what it's actually doing.
Totally understandable, your concerns are valid. I will have to figure out the CLI part, I would prefer to keep it private (at least for now), but I get it that people don't want to provide DB access to a completelly new tool.
And yes, you're absolutely right about the lack of screenshots. I realize now how important that is for trust and clarity. I’m working on improving the landing page with proper visuals, and I’m also exploring the idea of a live demo using an in-browser SQLite DB — that should let people try it instantly without setup. It’ll take a bit of time, but it’s now high on the priority list. Appreciate the feedback!
it screams it to me - wording such as "your concerns are valid", "yes, you're absolutely right..." and "I realize now how important...", and then usage of em-dash
Last time I was trying to be authentically me my response triggered a whole sub-thread about me using the word "subvention" and how funny Europeans sounds to Americans.
I have this too, many words I get from French and turn into English do exist in reality (they sound natural to me) and bam! there you have a snob who wants to show off :)
What is this obsession with the em-dash? For those who used LaTeX it is second nature, and a -- gets changed to an em-dash by a lot of editors or programs such as AutoHotkey
After reading all the comments, I can see there are two big issues here:
- The code is not open-sourced, and some people don't trust running it locally
- The landing page does not clearly show/explain what DataRamen is and how it works
I should've seen it coming. I will take the following actions to tackle these problems:
1) Open-source the CLI code. There are no super sophisticated algorithms behind it, so no need to keep it private.
2) Improve the landing page with screens and videos to showcase its features.
In addition to this, I will keep working on new features. I saw multiple comments mentioning SQLite support. Since it is possible to run SQLite directly in the browser, I might as well use it as a live demo where you can try the tool with a dummy DB without installing it locally (can't promise it, I have to see the feasibility of this project).
Where's the code? The NPM page says it is MIT licensed but I do not see any links to a source repo.
I think most people would be wary of running random npm modules to which they will be giving database credentials and passing through their actual data.
You're right, and you're not the only one who's raised this, totally fair concern. As a developer myself, I get why running a CLI tool that touches your databases without access to the source is a hard sell.
I hadn’t initially planned to open source it, but this feedback is making me seriously reconsider. At the very least, more transparency is clearly needed, and I’m thinking through the best way to approach that.
Curious though, would you feel any more comfortable if it were a packaged desktop app (with no source) instead of a CLI? Or is open code the baseline no matter the form?
There's a big difference between a precompiled app from a company you've possibly heard of (which exists as an entity and could be sued for creating something malicous) v.s. some random guy on the internet.
I personally would not run an arbitrary binary from somebody I've never heard of on my local machine. And definitely not give it database credentials or access. I also think anybody that is willing to do so is insane. There's so much garbage and malware on npm, that something that is installed via the @latest on npm is arguably even worse. Even if it's fine now, there's no telling when one of its deps could be compromised too.
Companies have to start somewhere though, lots of software exists that never was open source. I think he needs to get his tool in the hands of people who review dev tools.
> Companies have to start somewhere though, lots of software exists that never was open source
I think koolba's point was not as much about the tool being open-source as it is for a tool that runs on your machine and accesses your database with write permission, not having any guarantees it does the job it promises.
I could not agree more with him. This tool was born as a side project for my personal need, so I obviously use it without hesitation. But obviously, there is nothing to ensure you the tool won't drop your DB out of nowhere, or dumps your data somewhere else.
I think going open source will allow me to build some credibility for now.
PS. I use this tool daily, but I have to admit, in prod env I have read only user.
I get what he meant, but tools like Navicat as far as I know were unknown DB client tools, someone had to trust that it wouldnt mess up their PROD db somehow.
Then again, never use a new DB tool on a PROD DB, always test in lower environments.
Sure, if the product fits the market needs, some people will start using (and I can see there was an increase in CLI installations yesterday from NPM).
So hypothetically yes, you can build trust overtime (Navicat has over 20 years of development), for every N users who don't trust it now, there is 1 yolo guy who just said "Yeah, this might help me do my job".
I should've presented this post in a different way. A lot of people that came here expected production ready tool, while the reality is that I did this in my free time to help me do my job, I wrote landing page in 10 minutes, and I published this post to get some feedback to see if it is something that may be interesting.
And based on what I read, I think there is interest for this tool.
I see your point. Since it's unlikely that I'll become a trusted entity anytime soon, open-sourcing it is probably the right thing to do to build some credibility.
Yes, you can publish an NPM package without having a repository linked to it. Technically you can inspect the source code using "Code" feature on NPM, but in this case it is minified. You can see a lot of stuff tho (ex: query used to inspect database, endpoints, etc...), but obviously it is not as easy to read as not bundled source code (not to mention you can use WASM, which is unreadable).
You mean npm? Of course. There's no requirement the software being published have source or even be open source. It doesn't even have to be javascript. You can publish anything you'd like as long as it has a package.json.
> I would like to see sqlite support
Indeed, it is something I'm planing to add, but following all the feedback I got so far this will have to wait (landing page needs some work, plus a lot of people are having concerns regarding CLI tool not being open sourced)
> any value of having the frontend loaded from a website instead of just opening it in localhost ?
I want the CLI package to be as small as possible, and including 600kb React bundle in it is the exact oposite of small. Moreover, the idea in the future is for you to be able to connect to any host (be it cloud, localhost or selfhosted) from the same page (for example I have company self hosted server and a local server for my local databases).
You're absolutely right, I really dropped the ball on that. This is my first time launching a product like this, and I focused so much on building and writing the post that I overlooked the importance of visuals. The lack of screenshots is definitely hurting the presentation (and I can see it in the bounce rate).
I'll prioritize getting some clear screenshots and maybe even a short demo video up soon. Thanks for pointing it out, appreciate the feedback.
"Soon" being tomorrow, next week, next month? Just stating the obvious, but taking 30 minutes to do it now while you have traction on HN seems like a no-brainer.
I did a lot of things wrong this time (I should've seen coming all the negative feedback I got). The lesson I learned is not rushing things. I will likely have to get a step back and to rethink some stuff (including landing page).
Not yet, but following the comments on this post I will likely open source the codebase. It will help to both improve trust in the product and provide a place to report issues publicly.
This seems like a yargs compatibility issue (I kind of expected it to be problematic), I will probably switch to commander to handle CLI.
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.
Yes, a lot of people have complained about this, and I totally get it, I messed up the presentation part. Improving the landing page will likely be my top priority following this post.
Screenshots on the website would be very helpful. This sounds interesting, but would like to see what the actual UI is before setting anything up. It would also be good to link to the Github repo for the CLI part - I'm skeptical of giving an unknown tool access to my database without understanding what it's actually doing.
Totally understandable, your concerns are valid. I will have to figure out the CLI part, I would prefer to keep it private (at least for now), but I get it that people don't want to provide DB access to a completelly new tool.
And yes, you're absolutely right about the lack of screenshots. I realize now how important that is for trust and clarity. I’m working on improving the landing page with proper visuals, and I’m also exploring the idea of a live demo using an in-browser SQLite DB — that should let people try it instantly without setup. It’ll take a bit of time, but it’s now high on the priority list. Appreciate the feedback!
is this chatgpt? your comments read like chatgpt output
I do ask chatgpt to improve my messages, but the content is mine.
Honestly, that comment really does not seem very chatGPT-like.
it screams it to me - wording such as "your concerns are valid", "yes, you're absolutely right..." and "I realize now how important...", and then usage of em-dash
As mentioned in another comment, I used ChatGPT to improve grammar and rewrite a bit my messages. I stopped using it since.
It's okay to be authentically you
Last time I was trying to be authentically me my response triggered a whole sub-thread about me using the word "subvention" and how funny Europeans sounds to Americans.
¯\_(ツ)_/¯
I have this too, many words I get from French and turn into English do exist in reality (they sound natural to me) and bam! there you have a snob who wants to show off :)
What is this obsession with the em-dash? For those who used LaTeX it is second nature, and a -- gets changed to an em-dash by a lot of editors or programs such as AutoHotkey
I may have to stop using Em-dashes.
I'd second the screenshot recommendation.
But def looks very interesting and i like the simple minimal design on mobile. Logo's great too. Congrats on getting it out there!
Hi guys, thanks for all the feedback.
After reading all the comments, I can see there are two big issues here:
- The code is not open-sourced, and some people don't trust running it locally
- The landing page does not clearly show/explain what DataRamen is and how it works
I should've seen it coming. I will take the following actions to tackle these problems:
1) Open-source the CLI code. There are no super sophisticated algorithms behind it, so no need to keep it private.
2) Improve the landing page with screens and videos to showcase its features.
In addition to this, I will keep working on new features. I saw multiple comments mentioning SQLite support. Since it is possible to run SQLite directly in the browser, I might as well use it as a live demo where you can try the tool with a dummy DB without installing it locally (can't promise it, I have to see the feasibility of this project).
Check out asciinema for easy creation of CLI demos.
https://asciinema.org/
I don't have much to showcase in the CLI department (in case of DataRamen CLI is just to start the local server), but the tool looks great.
Where's the code? The NPM page says it is MIT licensed but I do not see any links to a source repo.
I think most people would be wary of running random npm modules to which they will be giving database credentials and passing through their actual data.
You're right, and you're not the only one who's raised this, totally fair concern. As a developer myself, I get why running a CLI tool that touches your databases without access to the source is a hard sell.
I hadn’t initially planned to open source it, but this feedback is making me seriously reconsider. At the very least, more transparency is clearly needed, and I’m thinking through the best way to approach that.
Curious though, would you feel any more comfortable if it were a packaged desktop app (with no source) instead of a CLI? Or is open code the baseline no matter the form?
There's a big difference between a precompiled app from a company you've possibly heard of (which exists as an entity and could be sued for creating something malicous) v.s. some random guy on the internet.
I personally would not run an arbitrary binary from somebody I've never heard of on my local machine. And definitely not give it database credentials or access. I also think anybody that is willing to do so is insane. There's so much garbage and malware on npm, that something that is installed via the @latest on npm is arguably even worse. Even if it's fine now, there's no telling when one of its deps could be compromised too.
Companies have to start somewhere though, lots of software exists that never was open source. I think he needs to get his tool in the hands of people who review dev tools.
> Companies have to start somewhere though, lots of software exists that never was open source
I think koolba's point was not as much about the tool being open-source as it is for a tool that runs on your machine and accesses your database with write permission, not having any guarantees it does the job it promises.
I could not agree more with him. This tool was born as a side project for my personal need, so I obviously use it without hesitation. But obviously, there is nothing to ensure you the tool won't drop your DB out of nowhere, or dumps your data somewhere else.
I think going open source will allow me to build some credibility for now.
PS. I use this tool daily, but I have to admit, in prod env I have read only user.
I get what he meant, but tools like Navicat as far as I know were unknown DB client tools, someone had to trust that it wouldnt mess up their PROD db somehow.
Then again, never use a new DB tool on a PROD DB, always test in lower environments.
Sure, if the product fits the market needs, some people will start using (and I can see there was an increase in CLI installations yesterday from NPM).
So hypothetically yes, you can build trust overtime (Navicat has over 20 years of development), for every N users who don't trust it now, there is 1 yolo guy who just said "Yeah, this might help me do my job".
I should've presented this post in a different way. A lot of people that came here expected production ready tool, while the reality is that I did this in my free time to help me do my job, I wrote landing page in 10 minutes, and I published this post to get some feedback to see if it is something that may be interesting.
And based on what I read, I think there is interest for this tool.
I see your point. Since it's unlikely that I'll become a trusted entity anytime soon, open-sourcing it is probably the right thing to do to build some credibility.
Didnt realize one can submit nmp without source? Is this really the case?
Yes, you can publish an NPM package without having a repository linked to it. Technically you can inspect the source code using "Code" feature on NPM, but in this case it is minified. You can see a lot of stuff tho (ex: query used to inspect database, endpoints, etc...), but obviously it is not as easy to read as not bundled source code (not to mention you can use WASM, which is unreadable).
You mean npm? Of course. There's no requirement the software being published have source or even be open source. It doesn't even have to be javascript. You can publish anything you'd like as long as it has a package.json.
Seems like a really cool project !! Do launch it on https://superlaun.ch , would love to have DataRamen there.
Sure thing, I have to polish it a bit before getting any more exposure, once it is in a presentable state I will push it on Super Launch as well.
Sure, thanks!!
You can find screenshots here: https://dev.to/9zemian5/tired-of-writing-sql-just-to-explore... (might be outdated, didn't test the tool)
On my part, I would like to see sqlite support and screenshots on the mainpage, also not a big fan of running an unknown command on my data.
Since you run locally, any value of having the frontend loaded from a website instead of just opening it in localhost ?
Hi, yes, the dev.to post is a bit outdated.
> I would like to see sqlite support Indeed, it is something I'm planing to add, but following all the feedback I got so far this will have to wait (landing page needs some work, plus a lot of people are having concerns regarding CLI tool not being open sourced)
> any value of having the frontend loaded from a website instead of just opening it in localhost ? I want the CLI package to be as small as possible, and including 600kb React bundle in it is the exact oposite of small. Moreover, the idea in the future is for you to be able to connect to any host (be it cloud, localhost or selfhosted) from the same page (for example I have company self hosted server and a local server for my local databases).
>GUI
Not a single screenshot on the page
You're absolutely right, I really dropped the ball on that. This is my first time launching a product like this, and I focused so much on building and writing the post that I overlooked the importance of visuals. The lack of screenshots is definitely hurting the presentation (and I can see it in the bounce rate).
I'll prioritize getting some clear screenshots and maybe even a short demo video up soon. Thanks for pointing it out, appreciate the feedback.
"Soon" being tomorrow, next week, next month? Just stating the obvious, but taking 30 minutes to do it now while you have traction on HN seems like a no-brainer.
I did a lot of things wrong this time (I should've seen coming all the negative feedback I got). The lesson I learned is not rushing things. I will likely have to get a step back and to rethink some stuff (including landing page).
Yeah I hate lacking screenshots but now I'm going to try it, so probably a good thing haha
Sounds very nice but doesn't seem to support Node v22 :/
``` Error [ERR_REQUIRE_ESM]: require() of ES Module /Users/cupid/.bun/install/global/node_modules/yargs/index.mjs not supported. ```
Is there a GitHub or similar where issues can be reported?
Not yet, but following the comments on this post I will likely open source the codebase. It will help to both improve trust in the product and provide a place to report issues publicly.
This seems like a yargs compatibility issue (I kind of expected it to be problematic), I will probably switch to commander to handle CLI.
A similar and bigger product I am aware of is Directus: https://directus.io/docs/getting-started/overview
This looks closer to something like Retool (an internal tooling builder), but yes, there is an overlap on some features
So this uses the local cli tool to allow your hosted code to connect to the db? Sounds a bit sketchy to me
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
Ok so it does work as I understood originally.
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.
I'd like to know what it looks like before investing my time in using a GUI tool.
Neat idea on paper though!
Yes, a lot of people have complained about this, and I totally get it, I messed up the presentation part. Improving the landing page will likely be my top priority following this post.
Saving this; may prove its utility in enterprise BU analysis.
nice work + cool name, congrats!
What a cool name !
Thanks! I was aiming for something fun and a little memorable — glad it landed well