Live data from Hacker News

Show HN: Kysely, a type-safe SQL query builder for TypeScript

kysely.dev

21–30 of 65 posts

Re: Show HN: Kysely, a type-safe SQL query builder for TypeScript

#21
post #9
post #5

Earlier quoted context omitted.

If you use it with kysely-codegen, it generates the types from your DB schema, guaranteeing they match. And the strings are verified at compile time - you can’t typo a table name, field name, etc., it won’t compile. Plus, from an ergonomics POV, it integrates very well with auto-complete. It’s very typesafe IMO, more so than most libs that interact with the the DB, where you hand-define the schemas and can more easil…

I didn't go deep into the docs, but the 'movie' on the homepage clearly shows string-based field name mappings so I instantly saw that as a red flag... Nice to know it's implemented better though.

These are literal string types. Its a feature of at least two languages that I know of:

Typescript: https://www.typescriptlang.org/docs/handbook/literal-types.h...

Scala: https://docs.scala-lang.org/sips/42.type.html

Typescript goes a step further has has things like template literal types: https://www.typescriptlang.org/docs/handbook/2/template-lite...

They are a little bit more than string mappings, and the mapping you do see is all codegen generated from the DB schema.

Re: Show HN: Kysely, a type-safe SQL query builder for TypeScript

#22
I typed up a comment saying how much I’d love to drop this in alongside my Prisma code so I can keep using the ORM for simple things and have the option to drop into SQL as needed. It ended asking if anyone knew whether such a thing was possible. I decided to check the docs one more time and… here it is! https://github.com/valtyr/prisma-kysely

I’m excited. I enjoy Prisma but SQL can be so expressive. Looking forward to trying this.

Re: Show HN: Kysely, a type-safe SQL query builder for TypeScript

#23
If you want to run SQL, write SQL.

The majority of your SQL will not require building dynamic where clauses or (dog forbid) dynamic joins.

Having your SQL as plain statements with simple placeholders (to create safe prepared statements) is the saner approach.

Not only can you pluck them into your favorite SQL tools and analyzers, but you will not be surprised by terribly performing queries, because you created them dynamically without understanding their complexity.

We've learned the hard lessons decades ago by misusing ORMs. While using alternative SQL syntax builders is avoiding many of those pitfalls, you will still inherit complexity by translating a SQL dialect to the builder pattern.

It is not worth it IMHO.

Re: Show HN: Kysely, a type-safe SQL query builder for TypeScript

#24
post #10
post #8

How does it compare to zapatos? https://jawj.github.io/zapatos/

We moved away from zapatos because the generated types are good only when selecting from single table. The moment we start selecting some subset of columns from a join of multiple tables, it is upto the developer to provide the right combination of pick and intersection of generated types and type safety takes a hit. The solution we use right now is ts-sql-query [1] which supports automatic type-safety for complex jo…

How does this compare with pgTyped[1]?

[1] https://github.com/adelsz/pgtyped

Re: Show HN: Kysely, a type-safe SQL query builder for TypeScript

#25
post #23

If you want to run SQL, write SQL. The majority of your SQL will not require building dynamic where clauses or (dog forbid) dynamic joins. Having your SQL as plain statements with simple placeholders (to create safe prepared statements) is the saner approach. Not only can you pluck them into your favorite SQL tools and analyzers, but you will not be surprised by terribly performing queries, because you created them d…

[deleted]

Re: Show HN: Kysely, a type-safe SQL query builder for TypeScript

#26
post #23

If you want to run SQL, write SQL. The majority of your SQL will not require building dynamic where clauses or (dog forbid) dynamic joins. Having your SQL as plain statements with simple placeholders (to create safe prepared statements) is the saner approach. Not only can you pluck them into your favorite SQL tools and analyzers, but you will not be surprised by terribly performing queries, because you created them d…

Because writing SQL is a drudge, you will write some helpers here and there. Before you know it, you have your own buggy non type safe SQL builder. This is vastly superior.

Re: Show HN: Kysely, a type-safe SQL query builder for TypeScript

#27
post #24
post #10

Earlier quoted context omitted.

We moved away from zapatos because the generated types are good only when selecting from single table. The moment we start selecting some subset of columns from a join of multiple tables, it is upto the developer to provide the right combination of pick and intersection of generated types and type safety takes a hit. The solution we use right now is ts-sql-query [1] which supports automatic type-safety for complex jo…

How does this compare with pgTyped[1]? [1] https://github.com/adelsz/pgtyped

I like pgtyped - when the queries are mostly static it is a great solution.

Solutions like ts-sql-query are better when you need to dynamically generate complex sql. With ts-sql-query it is very easy to create sql select statements where multiple individual where clauses, or even joins are conditional based on the incoming filters.

You can choose to use stored procedures etc. for the more complex cases while keeping pgtyped for 80% of the less dynamic use cases. We decided not to go that route to keep most of the application in typescript which we are more comfortable with.

Re: Show HN: Kysely, a type-safe SQL query builder for TypeScript

#28
post #23

If you want to run SQL, write SQL. The majority of your SQL will not require building dynamic where clauses or (dog forbid) dynamic joins. Having your SQL as plain statements with simple placeholders (to create safe prepared statements) is the saner approach. Not only can you pluck them into your favorite SQL tools and analyzers, but you will not be surprised by terribly performing queries, because you created them d…

Kysely is not an ORM, its a query builder with strong emphasis on type-safety and 1:1* mapping ("What You See Is What You Get") to SQL.

Projects writing raw SQL eventually end up implementing their own query building functionality. Which adds another thing to maintain and understand - that's also lacking in features and is not as type-safe.

Just use a well adopted query builder.

Re: Show HN: Kysely, a type-safe SQL query builder for TypeScript

#29
post #23

If you want to run SQL, write SQL. The majority of your SQL will not require building dynamic where clauses or (dog forbid) dynamic joins. Having your SQL as plain statements with simple placeholders (to create safe prepared statements) is the saner approach. Not only can you pluck them into your favorite SQL tools and analyzers, but you will not be surprised by terribly performing queries, because you created them d…

For me, Rusts SQLx has been a good option for this. Write plain SQL with a macro and have it verified against a dev database at build time, optionally to a typed anonymous struct to match your query results. The performance isn't incredible though.

Re: Show HN: Kysely, a type-safe SQL query builder for TypeScript

#30
post #20

Doesn't seem like it performs result set nesting on joins? For example with the one to many of owner -> pet, I'd like the results to look something like `{ person: Person, pets: Pet[] }[]`. Knex doesn't do this either (afaict) - wrote a few "deep" queries with some convoluted lodash to group things up but mostly gave up and just live with raw resultsets. I guess I still prefer that to a full on ORM, but that's really…

Have you read this recipe? https://kysely.dev/docs/recipes/relations
Post reply on HN