node-sql-template-strings
tsql
Our great sponsors
| node-sql-template-strings | tsql | |
|---|---|---|
| 6 | 3 | |
| 600 | 11 | |
| - | - | |
| 0.0 | 6.8 | |
| 12 days ago | 8 months ago | |
| JavaScript | TypeScript | |
| ISC License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
node-sql-template-strings
-
Write SQL Queries With Confidence (TypeScript + Postgres)
Ah, I see it. I'm assuming node-sql-template-strings or an equivalent?
-
I thought I knew what I was doing
There is also some other interesting use cases.
- DenoDB
-
Slonik: A PostgreSQL client with strict types, detailed logging, and assertions
Any reason you chose that over node-sql-template-strings [1], which looks very similar?
[1] https://github.com/felixfbecker/node-sql-template-strings
-
How do I prevent SQL injection in this function? I am using pg-promise
sql-template-strings is a really simple and elegant solution for parameterized queries.
tsql
-
Kysely: TypeScript SQL Query Builder
We use in prod variant of no 1. [0]. Why? Because:
* it's extremely lightweight (built on pure, functional combinators)
* it allows us to use more complex patterns ie. convention where every json field ends with Json which is automatically parsed; which, unlike datatype alone, allows us to create composable query to fetch arbitrarily nested graphs and promoting single [$] key ie. to return list of emails as `string[]` not `{ email: string }[]` with `select email as [$] from Users` etc.
* has convenience combinators for things like constructing where clauses from monodb like queries
* all usual queries like CRUD, exists etc. and some more complex ie. insertIgnore, merge1n etc has convenient api
We resort to runtime type assertions [1] which works well for this and all other i/o; runtime type assertions are necessary for cases when your running service is incorrectly attached to old or future remote schema (there are other protections against it but still happens).
[0] https://github.com/appliedblockchain/tsql
[1] https://github.com/appliedblockchain/assert-combinators
-
Objection to ORM Hatred
Exactly. I'm happy with tsql [0] - template based, with safe sanitation, helper renderers/combinators, used in production for several years, would recommend this approach.
[0] https://github.com/appliedblockchain/tsql
-
DenoDB
Personally I prefer functional combinators like interfaces [0]. Js/ts have tagged templates which enhances those type of interfaces a lot. It gives access to full set of functionality of underlying database, not just common denominator of all used. It allows arbitrary compositions etc.
[0] https://github.com/appliedblockchain/tsql/
What are some alternatives?
MySQL - A pure node.js JavaScript Client implementing the MySQL protocol.
denodb - MySQL, SQLite, MariaDB, PostgreSQL and MongoDB ORM for Deno
slonik - A Node.js PostgreSQL client with runtime and build time type safety, and composable SQL.
postgres - Postgres.js - The Fastest full featured PostgreSQL client for Node.js, Deno, Bun and CloudFlare
typed-knex - A TypeScript wrapper for Knex.js
PostgreSQL - PostgreSQL client for node.js.
trpc - 🧙♀️ Move Fast and Break Nothing. End-to-end typesafe APIs made easy.
dedent - ⬅️ ES6 string tag that strips indentation from multi-line strings.
JDBI - The Jdbi library provides convenient, idiomatic access to relational databases in Java and other JVM technologies such as Kotlin, Clojure or Scala.