Litdb – type safe SQL for JavaScript/TS
11–20 of 70 posts
Re: Litdb – type safe SQL for JavaScript/TS
#12Re: Litdb – type safe SQL for JavaScript/TS
#13My current project uses PostGIS which uses opaque types for storing geometry. Geometry columns are added to tables via a function instead of traditional alter table syntax, and select/where clauses on geometry columns need to use PostGIS functions to render the column into useable data.
Unless a system like Litdb includes an easy way to provide type definitions for function return types, it won't be usable with an extension like PostGIS without heavy use of escape hatches, at which point most of the value is lost.
Re: Litdb – type safe SQL for JavaScript/TS
#14I like it. First glance and they chose the "proper" order (from -> where -> select) over the classical order (select -> from -> where). Probably because that improves/enables autocomplete and typehandling. This is good
SELECT
COUNT(col_a) as count
WHERE
count > 0
Kysely uses (from -> select -> where), and allows joins and selects in multiple places, like (from -> join -> select -> join -> select -> where).Re: Litdb – type safe SQL for JavaScript/TS
#15Hmmm I've recently been evaluating https://www.kysely.dev after finding that Prisma can't support foreign data warehousing (FDW) with Postgres. I don't really know enough about Kysely yet to make an informed opinion between those two. If you know more than me, can you give me your take?? Edit: Hmmm perhaps based on the primary author's other repos ( https://github.com/mythz ) it looks like they're a fan of C#. Perhap…
I've been using a lot of bun:sqlite [2] lately which has an amazing DX and lets you create lots of stand-alone .ts scripts (i.e. without deps) to access SQLite DB's. The only issue is that I didn't want all my SQL queries to be coupled to a single driver, so I created litdb to provide a RDBMS-agnostic API + Query Builders so all my queries could easily be run on different DBs.
TypeScript has an amazingly powerful type system which let me build the ideal abstraction I wanted where I could use expressive SQL Expressions but still have typed references to our App's classes (tables) / properties (columns) to benefit from static analysis/intelli-sense during development whilst making it safe to refactor / find references / etc.
Things that are hard/impossible in C# is easy in TypeScript, e.g. the QueryBuilders lets you have a variable number of generic args which isn't possible in C# also it was much easier to support composable queries [3] than trying to combine multiple LINQ queries with shared references.
[1] https://docs.servicestack.net/ormlite/
Re: Litdb – type safe SQL for JavaScript/TS
#16I'm sure a lot of effort went into this, but I would rather raw dog my database layer with node-postgres/postgres.js and zod. The decorator heavy implementation is visually very busy. Also, I would not consider any SQL toolkit for serious use unless it comes with a sufficiently competent code generation accompaniment.
My feelings are similar and I cringe every time I see a "typesafe" db interface that doesn't run time validate the data.
Re: Litdb – type safe SQL for JavaScript/TS
#17What does a migration look like with something like this?
Re: Litdb – type safe SQL for JavaScript/TS
#18You can use real SQL and get type-safety just using typescript’s “… as MyType”. Of course it blows up if the database doesn’t match up, but so does this, I think. (Yes, you may want some mechanisms to validate the data has the expected form.)
Re: Litdb – type safe SQL for JavaScript/TS
#19It seems like a step back to have to write SQL in Javascript syntax with a non-standard API. You can use real SQL and get type-safety just using typescript’s “… as MyType”. Of course it blows up if the database doesn’t match up, but so does this, I think. (Yes, you may want some mechanisms to validate the data has the expected form.)
The idea is that your App models represents your database's schema which your App's logic is bound to. You can also use litdb schema APIs [1] to create your database tables so that they're in sync.