I asked the same thing on Discord where he also showcased it. He answered the question with this.
> I wanted to make something that makes intuitive sense to me, and I wanted to make a sql version of what lazygit does, namely you can just jump in and there's no need for external documentation. To navigate the harlequin with keyboard only you have to learn the keybindings. Also I though it was quite hard to connect to databases via the cli and install adapters (again, documentation necessary). I wanted to have a tool that you can just run and its intuitive. There's definitely more features in harlequin and I went with more lightweight, though sqlit has SSH tunnels, which harlequin lacks.
When I linked lazysql[0], he replied with this
> That was my original inspiration. Same problem with harlequin, I didn't feel like it was intutive and to follow the "lazy" mindset of lazydocker and lazygit, it should just be easy and not require looking up keybindings. Lazysql ended up with too many features for my taste to the point it was difficult to use
I've recently been trying to find a good SQL TUI client, and one of the ones I tried was Harlequin. The main disadvantage, which every other SQL TUI I tried also suffers from, is that they don't comprehensively show every type of database object in the browser pane (e.g. tables, views, indexes, procedures). For example Harlequin only shows tables. This means that when you want to view one of the missing ones, you have to run a query. This means that you have to already know that the object you are looking for exists: there's no way to get a good overview of what you have in the database just by glancing at the browser.
For me this sort of defeats the point of having a TUI in the first place.
It seems like the OP's offering has the same problem, although it does offer more objects than Harlequin. I'll be bookmarking it to see how it develops.
I generally agree. AI is far from being good enough to ship entire apps on its own. So for now it's more like a kind of "power templating assistant" for devs who already know what they're doing
that said, the article says "Why buy a CRM solution or a ERM system when “AI” can generate one for you in hours or even minutes"
and I'd say that it's also wrong to see it that way, because the issue with "rolling your own" is not so much shipping the initial version, than maintaining and developing and securing it over time. This is what takes a lot of manpower, and that's why you usually want to rely on an external vendor, who focuses exclusively on maintaining and updating that component, so you don't have to do it on your own
I think it started as some kind of CI/CD tools, then they jumped on the AI hype and they started to use it to make it possible to run agents in containers easily... perhaps to do automated actions on CI/CD pipelines that use agents (eg try to solve some minor bugs automatically when you push on a branch, etc)
Although I'm not sure if that's so much a value-added? It's not so hard to just create a container and launch an agent in it.
The whole interesting thing was to use actual programming languages for Docker build, which I think was what they initially tried to do, but now it's a bit incomprehensible... I guess conceptually Dagger relates to Dockerfile a bit like Pulumi related to Terraform?
I've tried it, but there's too much "sorry not in the open-source edition, please buy the entreprise edition" stuff all around, which makes it quite unusable
I was interested in the beginning for CI/CD, but then they tried to take a kind of "AI-oriented" view in order to ride the AI wave, and the value prop of their tool was completely muddied up...
Unrelated, but I bought a walking pad, and because I often use it at home while working on the laptop, and I wanted a nice UI to track the speed/time etc, I just asked claude to do one:
What are the typical uses of PostgREST? is it just when you want to make your database accessible to various languages over HTTP because you don't want to use an ORM and connect to your db? But besides that, for an entreprise solution, why would you use PostgREST to develop your backend rather than, say, use an ORM in your language and make direct queries? (honest question)
You skip the backend entirely and query from the frontend. PostgREST and Postgres is your backend. If you want extra sauce on top you route those paths to an application that does whatever extra imperative operations you need.
So a kind of "mini-Firebase" ? and then you have security through row-based security?
But this also means your users can generate their own queries, possibly doing some weird stuff taking down the db, so I assume it's more for "internal tools"?
This always sounds super messy to me but I guess supabase is kind of the same thing and especially for side projects it seems like a very efficient setup.
reply