こんにちは。DevOps芸人と化して久しいAndyです。 2020年の秋にTypeScript 4.1へ[Template Literal Types](https://www.typescriptlang.org/docs/handbook/2/template-literal-types.html)が導入され、そのインパクトに俄かに一部の界隈がザワついたのは記憶に新しいかと思います。今回は型プログラミングの可能性を大いに押し広げたTemplate Literal Typesを用いてSQL文を型レベルで解析し、その実行結果を型情報として導出するための[sqlpture](https://github.com/andoshin11/sqlpture)というライブラリを作ったので紹介します。 Embedded content: https://github.com/andoshin11/sqlpture SQLの実行/検証対象はPostgreSQL v13です。 ## tl;dr - SQL文を型レベルで解析・評価して返り値型を取得できるmini interpreterを作ったよ - 型レベルのSQL validatorも作ってるよ - 実際にNode.js(TS)からPostgresに安全にSQLを発行するexample repositoryのご紹介 ![get query result type from SQL](//images.ctfassets.net/2p1otbbee5vt/5xe8EA30B9Ej8pqD2uvP8s/91b486b3021019e48d4c802072eed614/Screen_Shot_2021-02-23_at_14.44.10.png) ## 目次 1. [Template Literal Typesのおさらい](#about-template-literal-types) 2. [型レベルSQLインタプリタ](#type-level-sql-interpreter) 1. [先行事例](#previous-work) 2. [作るもの](#what-to-develop) 3. [SQL Parser](#sql-parser) 4. [SQL Evaluator](#sql-evaluator) 5. [SQL Validator](#sql-validator) 6. [正しいクエリのサジェスチョン](#suggest-valid-query) 3. [実例紹介](#real-world-usecase) 1. [DBの立ち上げ](#starting-up-database) 2. [API Serverの起動・変更](#starting-up-server) 3. [Databaseの型はどこから？](#codegen-schema-type) 4. [最後に](#closing)

Template Literal Typesのおさらい

本題に入る前に、改めて[Template Literal Types](https://www.typescriptlang.org/docs/handbook/2/template-literal-types.html)についておさらいしておきましょう。(すでにご存知の方は[こちら](#type-level-sql-interpreter)までskip!) TypeScriptにはversion 4.0以前より文字列全般を扱う `string types`の他に `string literal types`というliteral型が存在していました。 ```js type T1 = string type T2 = ‘hello, world’ const val1: T1 = ‘random string’ // `string types`にはどのような文字列もassignが可能 const val2: T2 = ‘hello, world’ // `string literal types`には特定の文字列しかassignすることができない ``` Template Literal Typesはこれを拡張したものとなり、シンタックスとしてはJavaScriptの[template literal string](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals)と同じような記法で記述する型となります。 ```js type World = 'world' const _World: World = 'world' type Hello = 'hello' const _Hello: Hello = 'hello' type Greeting = `${Hello}, ${World}` // 複数のstring literal typesから新たなliteral typesを構築 const _Greeting: Greeting = 'hello, world' ``` また、上記のシンプルなliteral型合成に加えて `Uppercase`, `Lowercase`, `Capitalize`, `Uncapitalize`という強力な組み込み型ヘルパーも導入されたことでより柔軟で汎用性の高い型定義が可能となりました。 ```js type EventHandler = `on${Capitalize}` type T1 = EventHandler<'change'> const funcName1: T1 = 'onChange' ``` template literal syntaxを用いて動的な型合成・型整形が行えるようになったことの他に、literalに対するinference(部分推論)が大幅に強化された点も重要なポイントです。 ```js // `onSomething`というシグネチャを満たすliteral型からon以降の部分のみを取得 type ExtractEventName = T extends `on${infer EventName}` ? Uncapitalize : never type T1 = 'onClick' const eventName1: ExtractEventName = 'click' // 動的パラメータを持つURIからパラメータ変数のみを抽出 type ParamFromTemplate = T extends `:${infer P}` ? P : never; type ExtractParamNames = T extends `${infer T}/${infer U}` ? ParamFromTemplate | ExtractParamNames : ParamFromTemplate type T2 = '/api/v1/users/:userId/posts/:postId' type T3 = ExtractParamNames const paramNames: T3[] = ['userId', 'postId'] ``` 上記の例だけでもその可能性の一端を感じていただけたのではないかと思います。実際の活用例としては[awsome-template-literal-types](https://github.com/ghoullier/awesome-template-literal-types)というレポジトリに事例がまとまっているので興味のある方はそちらをご参考ください。 Embedded content: https://github.com/ghoullier/awesome-template-literal-types また他の静的解析言語における型レベル文字列インタプリタの事例として、[@lotz](https://twitter.com/lotz84_)先生がHaskellの実装を紹介してくれました！こちらも要チェック！ Embedded content: https://zenn.dev/lotz/articles/85577e9d9059cd9e1245

型レベルSQLインタプリタ

本題です。型安全にDB通信を行うしくみとしては、各プログラミング言語で実装されたORMを介する方式が一般的でしょう。そんなORMの裏側に目を向けてみると、黒魔術といって差し支えないようなquery builderが動いているケースがほとんどで、生のSQLチューニングに慣れた人間からすると「ｳｯ」なることも正直少なくありません。とはいえActive Record以降の最近のORMはどれも優秀なので、特に不便せず安全なDB通信が行えてかつ型情報も得られるとすれば一アプリケーション実装者としては使わない手はないかと思います。(本記事もその優位性を否定するつもりは全くありません。) しかしそのようなORMが重宝されるのはある意味「SQLの仕様そのものの複雑性」やそれを取り巻く開発環境の貧弱に起因しているのかな、とも思うわけです。極端に言うなれば、プログラム言語自体に生SQLのインタプリタを積めばORMはいらなくね？という主張ですね。「もっと安全にSQLを書きたいなー」「ランタイムに与えるSQLの記述結果がそのまま型情報として展開できたら便利だなー」そういった積年の思いに対してTemplate Literal Typesの登場はまさに僥倖でした。

先行事例

型レベルでSQLを扱う実装としてはすでに[ts-sql](https://github.com/codemix/ts-sql)というライブラリが知られています。こちらは簡易的なSQL parserを備えた型レベルdatabase実装となっており、実際のDB通信には利用できないものの型レベルのSQL TokenizerやAST(抽象構文木)の実装など参考になる部分が非常に多いです。今回はこちらのParser実装を踏襲・拡張していくアプローチで取組んで行こうと思います。 (※ ちなみにTypeScriptやHaskell以外の言語も調べてみましたが、一般的なプログラミング言語で型レベルのSQLリテラルインタプリタを実装している言語やライブラリは見当たりませんでした)

作るもの

SQL mini interpreterの実装にあたって必要なもの・欲しいものはザックリこんな感じ - **SQL Parser:** リテラルとして与えられたSQL文 → AST(抽象構文木)に変換するための解析器 - **SQL Evaluator:** Databaseのschemaに対してパースしたSQL Treeを適用するための評価器。 SELECTやJOINの挙動などもこいつがシミュレート。 - **SQL Validator:** 任意のschema(テーブル構造)に対する命令分(SELECT, INSERT, UPDATE, etc...)およびパラメータの整合性検査器 - **(AST Printer):** パースされたASTからもとのSQL文に復元するための出力器

SQL Parser

前述の[ts-sql](https://github.com/codemix/ts-sql)のParser実装を参考にさせていただきました。入力となるSQL文に対して愚直にConditional TypesとTemplate Literal Type Inferenceを用いてAST Nodeを作成していく作業になります。例として SELECT文の解析順序を紹介するとこんな具合に。 1. Statement(SELECT, INSERT, UPDATE, etc...)の判定 2. select_listと `FROM`以降の部分の分離 3. select_listのtokenizeとfield指定部分、column alias、column source等の解析 4. `FROM`以降のclauseをtokenizeし、末尾から先頭に向かって順番に解析( `OFFSET` → `LIMIT` → `WHERE` → `JOIN` → `FROM`) 5. `JOIN` clauseや `FROM` clause中のTable SourceおよびAliasの解析実際に下記のQueryをASTに変換した様子です。 ```js const Q1 = 'SELECT customer.first_name, customer.last_name, rental.rental_date rented FROM rental INNER JOIN customer ON rental.customer_id = customer.customer_id;' type T1 = typeof Q1 type R1 = Parse // R1の型は下記のようになる type T1AST = { fields: [ FieldSpecifier, /* Alias */ Identifier<"first_name">>, FieldSpecifier, /* Alias */ Identifier<"last_name">>, FieldSpecifier, /* Alias */ Identifier<"rented">> ], from: TableSpecifier, /* Alias */ Identifier<"rental">>, where: Expression.BooleanLiteral, limit: NumericLiteral<-1>, offset: NumericLiteral<0>, joins: [ InnerJoinSpecifier< /* From */ TableSpecifier, Identifier<"customer">>, /* Where */ Expression.BinaryExpression< /* Left */ MemberExpression<"rental", "customer_id">, /* Operator */ "=", /* Right */ MemberExpression<"customer", "customer_id">>> ] } Eq // true ``` 後述のEvaluatorやValidatorがconsumeしやすいように正規化されたNode Treeとなっていることが分かりますね。同様のParserをSELECT以外の命令文についても実装していきます。現在までにサポートしているNodeの種類はこちらから確認できます。 [src/AST.ts](https://github.com/andoshin11/sqlpture/blob/master/src/AST.ts)

SQL Evaluator

上述のようにAST化したSQL文を評価して、実際のDBが返す実行結果を型レベルでシミュレーションする仕組みとなります。具体的には、 - SELECT対象のフィールド型をDB Schemaの任意のTableから取得する - フィールド型のKey名をColumn Aliasに置き換える - 複数TableがJOINされた後のSchema型をシミュレートする - etc... といった処理が該当します。ロジックが各所に散らばってはいますが、気になる方はこちらをご確認ください。 [src/Evaluator.ts](https://github.com/andoshin11/sqlpture/blob/master/src/Evaluator.ts) 実際の例を見てみましょう。下記のようなcustomer, address, cityという3つのテーブルがあるとします。 ```bash dvdrental=# \d customer; Table "public.customer" Column | Type | Collation | Nullable | Default -------------+-----------------------------+-----------+----------+----------------------------------------------- customer_id | integer | | not null | nextval('customer_customer_id_seq'::regclass) store_id | smallint | | not null | first_name | character varying(45) | | not null | last_name | character varying(45) | | not null | email | character varying(50) | | | address_id | smallint | | not null | activebool | boolean | | not null | true create_date | date | | not null | 'now'::text::date last_update | timestamp without time zone | | | now() active | integer | | | dvdrental=# \d address; Table "public.address" Column | Type | Collation | Nullable | Default -------------+-----------------------------+-----------+----------+--------------------------------------------- address_id | integer | | not null | nextval('address_address_id_seq'::regclass) address | character varying(50) | | not null | address2 | character varying(50) | | | district | character varying(20) | | not null | city_id | smallint | | not null | postal_code | character varying(10) | | | phone | character varying(20) | | not null | last_update | timestamp without time zone | | not null | now() dvdrental=# \d city; Table "public.city" Column | Type | Collation | Nullable | Default -------------+-----------------------------+-----------+----------+--------------------------------------- city_id | integer | | not null | nextval('city_city_id_seq'::regclass) city | character varying(50) | | not null | country_id | smallint | | not null | last_update | timestamp without time zone | | not null | now() ``` 下記のようにクエリを実行して返り値型を検証してみましょう！ ```js import { Query } from 'sqlpture' import { DB } from './types' type EQ = A extends B ? B extends A ? true : false : false type R1 = Query<"SELECT * FROM customer;", DB> type T1 = EQ // true type R2 = Query<"SELECT first_name AS name, email FROM customer;", DB> type T2 = EQ // true type R3 = Query<"SELECT c.customer_id id, c.first_name, c.last_name, c.email, country.country, city.city, a.district, a.address, a.address2 FROM customer AS c INNER JOIN address AS a ON c.address_id = a.address_id INNER JOIN city ON a.city_id = city.city_id INNER JOIN country ON city.country_id = country.country_id WHERE customer_id = 1", DB> type T3 = EQ // true type R4 = Query<"INSERT INTO customer (store_id, first_name, last_name, email, address_id) VALUES (1, 'John', 'Smith', NULL, 5) RETURNING *;", DB> type T4 = EQ // true ``` Tableを3つ跨ぐようなJOIN Clauseでも(Alias含めて)問題なくシミュレートできているのが分かりますね。 SQLの仕様があまりに膨大すぎてまだまだ対応していないケースも多いですが、一般的なWebアプリケーションの利用ケースをカバーできるよう順次実装予定です。

SQL Validator

TypeScriptといえばやはり型検査！ということでバリデータも実装していきます。 SQL文の記述は長大になりがちで、専用のIDEを利用しない限り3回に1回はtypoするといっても過言ではありません(※自社調べ) [sqlpture](https://github.com/andoshin11/sqlpture)ではせっかくASTレベルでSQLリテラルを取り扱えるようになったので、DB Schemaと突き合わせてその整合性を検査する仕組みも実装しています。例として使用するDB Schemaはこちら。 ```js type DB = { dialect: "postgres" schema: { customer: { customer_id: number first_name: string last_name: string email: string } item: { item_id: number label: string } customer_item: { customer_id: number item_id: number amount: number } } } import { ValidateQuery } from "sqlpture" type Q1 = "SELECT first_name AS name, email FROM customer;" type V1 = ValidateQuery // true ``` いくつかの例を見ていきましょう。不正なテーブル名やフィールド名の検知 ```js type Q2 = "SELECT * FROM not_customers;" type V2 = ValidateQuery // false type Q3 = "SELECT name, tel FROM customer;" type V3 = ValidateQuery // false ``` WHERE句での存在しないフィールドへのExpressionを検知 ```js type Q4 = "SELECT email FROM customer WHERE first_names = 'John';" type V4 = ValidateQuery // false ``` 存在しないFieldへのINSERT文を検知 ```js type Q5 = "INSERT INTO customers (first_name, last_name, email) VALUES('John', 'Smith', 'test@example.com');" type V5 = ValidateQuery // false type Q6 = "INSERT INTO customer (first_names, last_name, email) VALUES('John', 'Smith', 'test@example.com');" type V6 = ValidateQuery // false ``` INSERTする値の過不足を検知 ```js type Q7 = "INSERT INTO customer_item (customer_id, item_id, amount) VALUES (1, 10);" type V7 = ValidateQuery // false type Q8 = "INSERT INTO customer_item (customer_id, item_id, amount) VALUES (1, 10, 100), (2, 20, 200, 2000);" type V8 = ValidateQuery // false ``` INSERTする値の型チェック ```js type Q9 = "INSERT INTO customer_item (customer_id, item_id, amount) VALUES (1, 10, 'NaN');" type V9 = ValidateQuery // false: ammount should be number type type Q10 = "INSERT INTO customer (first_name, last_name, email) VALUES('John', 'Smith', 1);" type V10 = ValidateQuery // false: email should be string type ``` Validate項目としては最低限といったところですかね？正直まだまだ精度が甘く、false positiveも多すぎて実用的とは程遠いですが、こちらもしばらくドッグフーディングをしながら改善に勤しみたいと思います。

正しいクエリのサジェスチョン

上記の `ValidateQuery`という型ヘルパーはあくまでtrue/falseでクエリの整合性検証結果を返してくれるもので、「実際にどの部分が間違えているのか？」という指摘は行ってくれません。 TypeScriptで任意の型との差分を表示してくれる仕組みとして真っ先に思いつくのは、ジェネリクスパラメータの `extends`制約を用いるものでしょう。 ![extends sample](//images.ctfassets.net/2p1otbbee5vt/X2CDsTbPt9Cx1ENUCu0lS/3e86fc4cc38fbbe74cd9ebb2df196326/____________________________2021-02-26_13.38.36.png) これを応用すれば「DB上に存在するTableに対してしかFROM/JOINが行えない」といったように制約を適用できそうです。 ![invalid from clause](//images.ctfassets.net/2p1otbbee5vt/2gn9GVzyagVEWVGuOQ8s4Y/c0502f4dc78f2e5fe7cb4212766f4d75/____________________________2021-02-26_13.52.56.png) ![invalid join target](//images.ctfassets.net/2p1otbbee5vt/4iMgwV3zhF7rdX3HhNjNqO/782298566ec9ec8cc86ff4acbfa21d0f/____________________________2021-02-26_13.55.34.png) エラーメッセージの読みやすさに難はありますが、概ね正しいFROMターゲットやJOINターゲットがサジェストされているように見て取れます。しかし残念ながらこのアプローチで検証できる内容は、あくまでDB Schema単体から「決定的である」もののみです。例えば「FROMターゲット」というクエリの構成要素については、DB Schemaが入力として与えられた時点でターゲット候補が指定可能ですね。ですが `SELECT c.email, a.city FROM customer AS c INNER JOIN address AS a ON c.address_id = a.id WHERE c.id = 100;`というAliasを含むクエリについて考えてみると、その整合性が確定するのは当然クエリの記述時となります。("c", "a"といったAliasの名称についてDB Schemaは知り得ない)。この問題をクリアするためにいろいろと試行錯誤しているのですが、僕のTS力が不足しているためスマートな解決方法がまだ思いついていません。また「任意のDB Schemaに対して発行可能なクエリパターンを網羅的に全て事前定義する」という要件の複雑度が高すぎて、100点のソリューションを用意するのは当面ムリそうです。しばらくは上述のValidatorを用いてクエリの整合性のみをbooleanで返し、「どこが壊れているか」というデバッグは個々の開発者に委ねたいと思います。

実例紹介

ここからは実際にWeb API Server + PostgreSQL DBでの利用方法を紹介していきます。 [こちら](https://github.com/andoshin11/sqlpture-example)がサンプルレポジトリです。 Embedded content: https://github.com/andoshin11/sqlpture-example

DBの立ち上げ

レポジトリをPullして `$ make start-db`を実行すると、Postgres Docker Containerが `localhost:15432`で起動します。初期状態ではなにもデータが入っていないので、 `$ make restore-db`を実行して下記のようなschemaを流し込んであげてください。(データは永続化されているため、2度目からは必要ありません) ![Sample DB Schema](https://github.com/andoshin11/sqlpture-example/raw/master/dvd-rental-sample-database-diagram.png) リストアが完了したら`postgres://postgres:mysecretpassword1234@localhost:15432/dvdrental`で疎通を確認し、上記のようなschemaが反映されていることを確認してください。

API Serverの起動・変更

`$ make start-server`を実行すると3010番ポートでExpressのAPI Serverが起動します。 (nodemonを走らせているのでserver/src/\*\*/\*.tsファイルを適当に編集すれば自動でリロードするはず) [server/src/index.ts](https://github.com/andoshin11/sqlpture-example/blob/master/server/src/index.ts)というファイルがサーバーやハンドラーの実装となっており、こちらを見ていただくと雰囲気がつかめるかと思います。 ```js import { Client, QueryResultBase } from 'pg' import { Query, ValidateQuery } from 'sqlpture' import { DB } from './types/db' type Result = QueryResultBase & { rows: Query } type ValidQuery = true extends ValidateQuery ? T : never class Repository { constructor(private client: Client) {} async query(queryStr: T, values?: any[]): Promise> { return this.client.query(queryStr, values) as any } async strictQuery(queryStr: ValidQuery, values?: any[]): Promise> { return this.client.query(queryStr, values) as any } } ``` 読みやすさのために多少変更していますが、上記のようなRepository classを通してPostgresへの通信を行っています。見て分かるようにこのファサードの役割はあくまで型ヘルパーですね。引数として渡したSQL文(JS Value)をジェネリックなString Literal Typeに推論し、[sqlpture](https://github.com/andoshin11/sqlpture)で処理した結果を返り値型として返しています。下記のように単純なメソッド呼び出しを行うだけで型付けされた返り値型が得られるはずです。 ![get query result type from SQL](//images.ctfassets.net/2p1otbbee5vt/5xe8EA30B9Ej8pqD2uvP8s/91b486b3021019e48d4c802072eed614/Screen_Shot_2021-02-23_at_14.44.10.png) またValidatorも利用することで不正なクエリ(下記の例だとinvalid field access)を型エラーとして検知できていることも分かります。 ![invalid insert query](//images.ctfassets.net/2p1otbbee5vt/19IhLEz30KM7Qn5lYsJyeH/736fed57e75fb23299b0da543099be40/____________________________2021-02-26_17.45.44.png) これからは、さらにNode.jsアプリケーションの開発が楽しくなるのではないでしょうか！

Databaseの型はどこから？

最後になりましたが、肝心のDB Schema型はどのように得れば良いでしょうか？こちらは対象となるDBやアウトプットを利用するFWに応じて多くのソリューションがありますが、個人的にPostgreSQLのSchema型を自動生成する際は[Schemats](https://github.com/SweetIQ/schemats)を利用しています。 Embedded content: https://github.com/SweetIQ/schemats 対応しているDBはPostgreSQLとMySQLのみですが、シンプルなコマンドでNullableやEnumも解析できてお手軽です。 sqlptureで利用するためにはこちらから `type Database = { dialect: string; schema: Record }`というシグネチャを満たすDatabase型に変換してあげる必要があるので、[こちら](https://github.com/andoshin11/sqlpture-example/blob/master/server/scripts/prepareDBType.js)のシンプルなスクリプトと併用してタスクランナーから実行しています。規模の小さいDBであれば型定義を手書きする運用でもよいでしょうが、やはり自動生成を行うと実装と解離するリスクを軽減できて良いですね。

最後に

今回はTypeScript 4.1で登場したTempalte Literal Typesの応用編として型レベルのSQL Interpreterを作ってみました。話のネタになれば良いなと思って始めたプロジェクトですが、手前味噌ながら「意外と実用的なのでは？」と思ったり。 Open APIやProtobufに対する型解析でTypeScriptのシステムでWeb API境界を安全に扱う仕組みは整い始めたので、これを機にDB境界も型安全に扱える日がくると良いなと思っています。興味のある方からのコントリビュートをお待ちしています！ Embedded content: https://github.com/andoshin11/sqlpture