Ability to use kysely as standalone sql builder

Currently Kysely requires to have some QueryExecutor defined which means that it is not stateless. However I wonder how much work it is to use kysely as a sql builder without an execution implementation, which means it only produces a CompiledQuery . To make it typesafe the CompiledQuery interface could have Result generic:

export interface CompiledQuery<Result> {
  readonly query: RootOperationNode
  readonly sql: string
  readonly parameters: ReadonlyArray<unknown>
  __result?: Result;
}

The CompiledQuery<Result> then can be executed by any driver and still provide the benefit of typesafety, e.g:

import { Pool } from "pg"
import {
  RootOperationNode
} from 'kysely'

export interface CompiledQuery<Result> {
  readonly query: RootOperationNode
  readonly sql: string
  readonly parameters: ReadonlyArray<any>
  __result?: Result;
}

const pool = new Pool()

async function executeQuery<TResult>(query: CompiledQuery<TResult>) {
  return await pool.query<TResult>(query.sql, query.parameters).then(d => d.rows);
}

This has a benefit that Kysely could be used as a stateless query builder and not requiring any connection to any database and managing the state. And easily be used on frontend as well.

What are your thoughts?

[ilijaNL]

Is it an attempt to abstract away query building and make it easily swappable? Or is it an attempt to future-proof the driver side?

Not really, I actually don’t care about the executor that much but it can be used for that as well. A benefit of that is that other tools and drives can take care of that (they only need to implement the execution of sql dialect, and for postgres, there are a lot open source packages available). Additionally tools like http://vitaly-t.github.io/pg-promise/helpers.html can be used to do some transformations on the generated sql.

However my use cases is more like this: Consider you have a mutation route with some side-effects to the database. Lets consider /create-user creates 2 side effects to the database:

1. insert user into user table
2. insert welcome email job into job table

They both should succeed or fail together. The most common solution is to wrap it into a transaction, execute both statements and commit. This however has few drawbacks. First I need to wrap this inside a transaction which makes it harder to test, secondly the connection for that transaction is longer open since it executes per statement and waits for response per statement. This can be really slow when working with edge computing or whenever the database is far from the api server.

Another approach is to generated all sqls with side effects as pure statements, concat the statements (postgres supports this) and send it to the database as a single statement. Big advantages of this is that it can be easily tested. Also all “mutations” are easy composable, you only need to return the side-effect statements and your route handler can execute all returned side-effect statements. You can read my article for more in depth: https://itnext.io/how-to-write-ddd-scalable-and-type-safe-nodejs-backends-e0711403a755. Currently you can achieve this with kysely, which I definetly will use for that, however I personally prefer to split the query-builder side from the execution side. Nevertheless I understand why it is made like this and I really appreciate what you have done.

For further discussion we can connect on discord.

[koskimas]

The change is too invasive and also a breaking change. Since there are multiple ways to get the type information already, I don’t think we should merge the PR.