tsql
PostgreSQL
tsql | PostgreSQL | |
---|---|---|
3 | 57 | |
11 | 11,922 | |
- | - | |
6.8 | 8.0 | |
8 months ago | 3 days ago | |
TypeScript | JavaScript | |
GNU General Public License v3.0 or later | MIT License |
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.
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/
PostgreSQL
-
Neon Is Generally Available: Serverless Postgres
pg doesn't do too well with serverless, dead connections are left in the pool (or something)
https://github.com/brianc/node-postgres/issues/2112
-
NodeJS Security Best Practices
If you don't want to use ORM then there are some other packages as well! For PostgreSQL we have node-postgres
-
Building Secure Neon-Infused Web Apps with Auth0, Express, and EJS
Interface with PostgreSQL database
-
Drizzle is just as unready for prime-time as Prisma, what else is there?
(Instead of the following with pg.)
-
Nile, Serverless Postgres for Modern SaaS
So far every JS framework that uses https://node-postgres.com works great and so no reason to think Drizzle wouldn't.
-
We migrated to SQL. Our biggest learning? Don't use Prisma
One thing that keeps coming up is that SQL equals low productivity. I don't think this is true. I think the culprit is that most developers are using to heavily abstracting SQL using ORMs like Prisma that hides the database and SQL logic.
Since building a SQL generator (https://aihelperbot.com) as a side project, I have become much more proficient in SQL and even though I am also locked into Prisma, I use the `queryRaw` all the time to execute raw SQL queries. You can understand the code without knowing Prisma API. It is more performant. For more complex SQL queries, I use the SQL generator for initial suggestions and adapt if needed.
For the next projects I build I want to use the minimal Postgres client (https://github.com/brianc/node-postgres) combined with a lightweight migration library.
-
Using AI I have departed from ORM and embraced SQL
For newer projects I use the small Postgres client. Initially my leap into SQL was lead by AI but as I refreshed and relearned SQL, I now use a mixture of AI and self-written SQL queries. Something like this is just easier to have AI do the grunt work and then adjustment as needed.
-
Credentials Leak with Knex
This was a known issue for pg developers, and they managed to fix it a long time ago (at the pg level), but the knowledge of this problem didn't reach Knex maintainers.
-
Why SQL is right for Infrastructure Management
Integrate the database into your application itself with a postgres client library allowing your applications to make infrastructure changes (like provisioning sharded resources for a client that wants isolation, or using a more accurate forecasting model to pre-allocate more resources before the storm hits).
-
What is your development stack for 2023?
node-postgres (raw sql, without ORM)
What are some alternatives?
denodb - MySQL, SQLite, MariaDB, PostgreSQL and MongoDB ORM for Deno
Prisma - Next-generation ORM for Node.js & TypeScript | PostgreSQL, MySQL, MariaDB, SQL Server, SQLite, MongoDB and CockroachDB
postgres - Postgres.js - The Fastest full featured PostgreSQL client for Node.js, Deno, Bun and CloudFlare
MySQL - A pure node.js JavaScript Client implementing the MySQL protocol.
TypeORM - ORM for TypeScript and JavaScript. Supports MySQL, PostgreSQL, MariaDB, SQLite, MS SQL Server, Oracle, SAP Hana, WebSQL databases. Works in NodeJS, Browser, Ionic, Cordova and Electron platforms.
trpc - 🧙♀️ Move Fast and Break Nothing. End-to-end typesafe APIs made easy.
MongoDB - The official MongoDB Node.js driver
JDBI - The Jdbi library provides convenient, idiomatic access to relational databases in Java and other JVM technologies such as Kotlin, Clojure or Scala.
Aerospike - Node.js client for the Aerospike database
sql-compose - A simple sql query composer for clojure.
Redis - 🚀 A robust, performance-focused, and full-featured Redis client for Node.js.