oleksandr_dem

Unfortunately I don't have much experience with Go, I did try it for the sake of trying it, and I see your point, it is a bit more complicated to write code compared to JS/TS (two languages I know very well) or even Java (disclaimer: I think Java sucks).

> I don't get this part. What special characters?

For example let's look at this code:

```

class ProductsController < ApplicationController before_action :set_product, only: %i[ show edit update destroy ]

  def index
    @products = Product.all
  end

...

```

You can see a bunch of special characters: < : , % [] @

For example, if I wanted to write the same code in Typescript, based on my setup I might just need do something like this:

```

instance.get("/products", () => ProductsRepository.find());

```

Where instance is my router instance (fastify, express, whatever) and ProductsRepository is a TypeORM repository. My before_action might just be a middleware I pass to the callbacks chain or register as global middleware

I'm not doubting DHH skills as web developer, actually, the reason I've dedicated my time listening to the podcast and writing this post is because I kind-of see his point. However, during my 10 years career (which is nothing compared to DHH, and I'm not saying that I'm right and he is wrong) I've learned what works and what doesn't (at least for me). And looking at Ruby on Rails my feeling is that it shouldn't work, but as stated in the post description, I've heard different people saying that Ruby is great- And so I'm wondering if they are just a small niche group or if it is as good as people say it is.

> "I don't know databases, so I found one way that worked and ran with it as an ORM"

This doesn't really play in favor of Ruby on Rails, the same applies to Typescript and Java (and I'm quite sure to any language that is popular with web developers).

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.

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 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.

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.

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)?

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

> 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.

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).

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).

This looks closer to something like Retool (an internal tooling builder), but yes, there is an overlap on some features

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).