What does HackerNews think of slonik?

A Node.js PostgreSQL client with runtime and build time type safety, and composable SQL.

Language: TypeScript

#12 in JavaScript
#6 in Node.js
#6 in PostgreSQL
#5 in PostgreSQL
#7 in TypeScript
It's nice that they implemented string templates essentially exactly the same way Javascript template literals and tag functions work. They even give an example of using it to create a prepared statement (e.g. DB."SELECT * FROM foo WHERE bar = \{inputParam}") which is exactly what many NodeJS libraries due, e.g. Slonik https://github.com/gajus/slonik, like sql`SELECT * FROM foo WHERE bar = ${inputParam}`;
I've found libraries like Zod useful when interacting with external data sources like a database. Slonik[1] uses Zod to define the types expected from a SQL query and then performs runtime validation on the data to ensure that the query is yielding the expected type.

I don't think it's necessary to use Zod/runtime validation everywhere, but it's a nice tool to have on hand.

[1]https://github.com/gajus/slonik

Demonstrate how easily and accidentally one can make an SQL injection with these:

https://github.com/porsager/postgres

https://github.com/gajus/slonik

Have you tried Slonik (https://github.com/gajus/slonik)? It won't generate types from queries automatically, but it encourages writing SQL vs. a query builder and allows type annotations of queries with Zod. Query results are validated at runtime to ensure the queries are typed correctly.
Definitely a lot of misconceptions around how this would work. Just check out something like slonik, https://github.com/gajus/slonik, which is an excellent implementation.

The example you gave actually isn't valid, because what you're doing is generating SQL dynamically, and that doesn't work the way prepared statements work. That is, you can't have a prepared statement like "select foo from bar where zed = ? order by ? asc", because with prepared statements the question marks can only substitute for VALUES, not schema names. So if you wanted to do something like that it slonik, it would fail. With slonik you CAN do dynamic SQL, that is guaranteed to be safe and checked at compile time with TypeScript, because you can nest SQL tagged templates. That is you can do this:

    const colToSortBy = useFoo ? sql`foo` : sql`bar`;
    const query = sql`select col from mytable order by ${colToSortBy}`;
In that case slonik will know how to safely "merge" the parent and child parsed SQL.
Slonik comes pretty close https://github.com/gajus/slonik. It does not inspect your DB schema, but has worked very well in our SQL-heavy architecture.
Does anyone know of a library similar to slonik[0] for SQLite in the NodeJS space?

I generally reach for TypeORM and have tried MikroORM lately but didn’t really like it.

But what I really want is something like slonik which is more focused on querying than relational mapping.

[0]: https://github.com/gajus/slonik

There are various non-ORM database libraries for TypeScript too. I develop Zapatos, but Slonik and pg-typed are probably better known.

https://jawj.github.io/zapatos/

https://github.com/gajus/slonik

https://pgtyped.vercel.app/

I've been a huge fan of Slonik, https://github.com/gajus/slonik, which makes it easy and safe to write direct SQL queries. The author of Slonik had a good article about the downsides of query builders, previously discussed on HN, that I totally agree with: https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf41...
This is my middle-ground solution for Python: https://github.com/bdowning/sql-athame

Still fundamentally manipulating SQL text (which is a feature as I don't want to learn a full DSL), but it handles wrangling embedded placeholders while you're composing stuff and some other common compositional tasks. It's worked well for me anyway but I'm under no illusions it'd be right for everyone.

Not an original concept regardless; my original version of this was in Node: https://github.com/bdowning/sql-assassin, but a few years after I wrote that (and mostly didn't use it) I found https://github.com/gajus/slonik which was very similar and much more fleshed-out; I rolled _some_ of its concepts and patterns into sql-athame.

Give slonik a try. It's a very nice step up from raw drivers https://github.com/gajus/slonik
You're being downvoted, but I completely agree. If you are on Node and Postgres I highly recommend using slonik - it makes it easy to just write SQL but at the same time makes it almost impossible to have mistakes like SQL injections:

https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf41...

https://github.com/gajus/slonik

We are not using an ORM. I am a pretty strong advocate against ORMs, but that is a topic for a different discussion. We have a set of DAO components that access the DB using Slonik, https://github.com/gajus/slonik (overview explaining the rationale for this library is at https://medium.com/@gajus/bf410349856c ).

Our app doesn't have a huge need for caching, but we use a mix of in-server-memory caching ( https://github.com/isaacs/node-lru-cache ) and Redis when we need a global cache.

On a related note, I've become a gigantic fan of Slonik, https://github.com/gajus/slonik, which simultaneously (a) makes it extremely difficult to expose SQL injection attacks while (b) still letting you write SQL in a very "natural" way using template literals.

It takes advantage of a somewhat-not-well-known feature of Javascript template literals in that you can apply functions to them, e.g. sql`SELECT foo FROM bar WHERE id = ${userEnteredValue}`. No need to manually escape userEnteredValue, the sql template literal function does it for you.

Specifically in Node.js, https://github.com/gajus/slonik has drastically improved the experience of writing and composing SQL queries. I am the author of Slonik.
I really like the unique approach of the annotated SQL files and can definitely see some use cases where it would be good to declutter the SQL from the code. For me personally, I'd be hesitant to add another build tool to my already bloated toolchain. Could create a special Babel-style "import" type that automatically transforms your code (JIT)? It could remove some of the friction in adoption (for Babel users at least).

Another one in a similar vein with strict typing and really nice SQL interpolation for Postgres: https://github.com/gajus/slonik

Following are the alternatives :-

Action text in RoR <=> DraftJS (Isomorphic ReactJS plugin with server side rendering), Froala (compatible with most of SPA frameworks)

Active Record in RoR <=> SequelizeJS (ORM), Slonik(Non-ORM, my recommendation) in NodeJS

Action Cable in RoR <=> WS, Socket.io 2.0 (recommended)

DraftJS - https://github.com/facebook/draft-js

Froala - https://www.froala.com/wysiwyg-editor

SequelizeJS - https://sequelize.org/master/

Slonik - https://github.com/gajus/slonik

WS - https://github.com/websockets/ws

Socket.io - https://socket.io/

FYI, if you want a decent Postgres client, check out `slonik` [0]. It doesn't support migrations, but there are other tools for that [1].

[0] https://github.com/gajus/slonik

[1] https://github.com/mmkal/slonik-tools