In my experience, it is almost as bad as ORM. It creates the same issue the author commented on, where complex queries become difficult to maintain and understand.
If you go a little beyond the basic SQL commands, it's going to introduce a complexity to the point that you won't be able to understand what is being executed in the database. It will end up requiring debugging your application to understand the query that is being generated.
Plain SQL and sqlc provide way better solutions for the mid/long-term.
We all agree that plain SQL is the best, but sometimes, writing raw queries, especially for simple queries, can be annoying.
About sqlc, as you have to depend on it like sqlx, ..., it's not a good choice, at least for me.
squirrel, or any other query builders that are compatible with sql.DB helps me to write SELECT a,b,c FROM foo WHERE bar... easier and with fewer mistakes.
And yes, when I need to write complex queries, just can skip using squirrel in that specific function/method. but I don't want to write raw queries for everything.
As far as it's compatible with sql.DB and can be replaced easily and is stable, it's fine.
But then you will have two distinguished ways to write queries in your system.
But of course, like anything in engineering, the answer to a choice is always "It depends". If you have a system with low complexity and the chances of having complex queries are extremely low, query builders might be more helpful.
But this, in my experience, unfortunately, hasn't been my reality in most places I worked. If you end up having half of your queries written in plain SQL and another half using a query builder, it might create more mess than solve the problem.
I recommend you trying https://github.com/Masterminds/squirrel
In my experience, it is almost as bad as ORM. It creates the same issue the author commented on, where complex queries become difficult to maintain and understand.
If you go a little beyond the basic SQL commands, it's going to introduce a complexity to the point that you won't be able to understand what is being executed in the database. It will end up requiring debugging your application to understand the query that is being generated.
Plain SQL and sqlc provide way better solutions for the mid/long-term.
Agree but...
We all agree that plain SQL is the best, but sometimes, writing raw queries, especially for simple queries, can be annoying.
About sqlc, as you have to depend on it like sqlx, ..., it's not a good choice, at least for me.
squirrel, or any other query builders that are compatible with sql.DB helps me to write SELECT a,b,c FROM foo WHERE bar... easier and with fewer mistakes.
And yes, when I need to write complex queries, just can skip using squirrel in that specific function/method. but I don't want to write raw queries for everything.
As far as it's compatible with sql.DB and can be replaced easily and is stable, it's fine.
But then you will have two distinguished ways to write queries in your system.
But of course, like anything in engineering, the answer to a choice is always "It depends". If you have a system with low complexity and the chances of having complex queries are extremely low, query builders might be more helpful.
But this, in my experience, unfortunately, hasn't been my reality in most places I worked. If you end up having half of your queries written in plain SQL and another half using a query builder, it might create more mess than solve the problem.
Yeah it's great, never used it though
Bun ORM is more performant than GORM
https://bun.uptrace.dev/