NestJS Prisma on Fargate構成で作るWeb API開発Tips

Transcript

1. NestJS x Prisma on Fargate構成で作るWeb API開発Tips 2 02 3 / 07 / 08 CX事業本部 髙橋俊⼀ a.k.a shuntaka
2. スライド ２
3. スライド 3 speakerdeck.com/shuntaka (⼀番最新のスライド) #devio 2 0 23 @shuntaka_jp
4. ⾃⼰紹介 4
5. ⾃⼰紹介 5 shuntaka/髙橋 俊⼀ 主な業務内容 ‧サーバサイド ‧インフラ クラスメソッド CX事業本部 19年8⽉⼊社 基本的にAWSでサーバーサイド開発することが多いです！ ‧IoTバックエンド開発 ‧IoTエッジソフトウェア開発 shuntaka.dev/who 詳細はこちら! 好きな技術 ‧TypeScript/Go/Neovim
6. ⾃作ツールの宣伝(1秒) 6 Goを使ったCLIの個⼈開発が⼤好きです！ ‧oax(💥 CLI for OpenAI's ChatGPT) ‧ddbrew(🍺 Simple DynamoDB utility CLI) ‧gh-p 2 (✨ GitHub CLI extension ProjectV 2 utility) etc..
7. 本セッションについて 7
8. サンプルコード 8 本セッションで解説する内容やコードは、動作するものをGitHubに⽤意しておりま す。 github.com/shuntaka 9576 /devio 2 023 -nest セッションで必要な範囲は、スライドに書いていますので、後⽇全体感を確認した い場合にご利⽤ください。
9. 前提 9 ライブラリは、2023年6⽉29⽇時点で最新ものを利⽤しています。 prisma: 4 . 1 6 . 1 @nestjs/apollo: 12 . 0 . 7 @nestjs/graphql: 12 . 0 . 7 詳細は、web-api/package.jsonを参照してください。 データベースエンジンは、Aurora(MySQL)を前提としています。
10. セッション概要 1 0 ‧技術選定 ‧インフラ構成 ‧プロジェクト構成 ‧NestJSのホスティング ‧NestJS(GraphQL)のTips ‧PrismaのTips ‧その他でやって良かったこと ‧さいごに ‧参考⽂献
11. 技術選定 1 1
12. チーム構成 1 2 チームの体制 ‧サーバサイド(2名) ‧フロントエンド(2名) ‧UXデザイナー(1名) ‧デザイナー(2名)
13. システム要件 1 3 システムの要件として、以下の通り => 複雑な検索や集計の要件を考慮し、RDBMSを利⽤することに決定 ‧⼀般のお客様がワード⼊⼒して、検索するWebアプリ ‧認証はLINE ‧検索要件  ‧複数の条件を使った絞り込み検索機能  ‧特定条件で絞り込んだものを集計し、上位複数を表⽰する機能
14. ホスティング環境 1 4 ‧Amazon Elastic Container Service (Fargate) ‧AWS App Runner 技術選定時(2022年9⽉) AWS App RunnerはAWS WAFに対応しておらず、 ECS(Fargate)を採⽤。 今選定するならデプロイの観点で懸念はあるが、App Runnerも選択肢に⼊る。
15. GraphQLの採⽤ 1 5 以下の理由でGraphQLを採⽤した ‧効率的なデータフェッチ ‧ApolloやRelayといった強⼒なクライアントライブラリの存在 ‧shemaファイルで型定義をバックエンド、フロントエンドで共有可能 ‧NestJSのGraphQLエコシステムが成熟しており、導⼊が容易
16. Webアプリケーションフレームワークの技術選定 1 6 私⾃⾝サーバーレスでフレームワークを使わずにアプリを作ることが多く、Web アプリケーションフレームワークを使うことに対する不安があった ‧カスタマイズ性が少なく、柔軟に実装ができなそう ‧FWのお作法を学ぶ時間がかかりそう
17. Webアプリケーションフレームワークの技術選定 1 7 NestJSの社内外の評判を⽬にすることが多く検討 ‧TypeScriptサポート ‧DI(依存性の注⼊)のサポート ‧GraphQLサポートが⼿厚い ‧ドキュメントが豊富 Quick Startをやってみて、GraphQL(Apollo Server)との連携部分が成熟してい る印象で、Dataloaderを使ったGraphQLのN+ 1 問題にも対応できそうと感じた 結果として、前のスライドのような問題はなかった
18. ORM 1 8 ‧Prisma ‧TypeORM 候補としては以下のORMがあった ‧スキーマに合わせて⾃動⽣成される型安全なクライアントライブラリ ‧Prismaの機能としてN+ 1 問題の最適化機能がある TypeORMと⽐較し、Prismaを採⽤した理由は以下の通り 結果的には、あまりメリットを活かせなかった(詳しくは後述の章)
19. Infrastructure as Code 1 9 IaCには、CDKを採⽤ ‧社内で利⽤が活発、CDKのサンプルコードが豊富 ‧⾃分が慣れている
20. プロジェクト構成 2 0
21. プロジェクト構成 2 1 モノレポを採⽤、ディレクトリルートは以下のような形式 infra/ CDK定義(フロントエンド,サーバサイド) monitoring/ CDK定義(監視系) backend/ NestJSアプリケーションコード frontend/ Next.jsアプリケーションコード schema.graphql GraphQL定義ファイル …
22. インフラ構成 2 2
23. 構成図 2 3
24. CloudFormationスタック構成 2 4 1. ネットワークスタック(VPC, 踏み台) 2. バックエンド系  2.1. バックエンドアプリスタック(ECS, ALB)  2.2. バックエンドECRスタック 3. フロントエンド系  3.1. フロントエンドアプリスタック  3.2. フロントエンECRスタック 4 . GitHub Actionsデプロイ⽤ロールスタック(GitHub Actions OIDC to AWS) 5. 画像配信CDNスタック
25. NestJSのホスティング 2 5
26. コンテナイメージ作成 2 6 FROM node:18-alpine3.17 AS build ENV GRAPHQL_SCHEMA_PATH "./schema.graphql" WORKDIR /app COPY server/package.json ./ COPY server/package-lock.json ./ NODE_ENV=production RUN npm ci COPY schema.graphql ./ COPY server/tscon fi g.build.json ./ COPY server/tscon fi g.json ./ COPY server/schema.prisma ./ COPY server/.env ./ COPY server/src ./app RUN npx prisma generate RUN npm run build RUN npm install --omit=dev イメージサイズ削減のため、マルチステージビルドの活⽤ ビルド後は開発⽤のライブラリ群を削除する Prismaの型定義ファイルの⽣成 ホストOSから必要なファイル群を取得 コード
27. コンテナイメージ作成 2 7 FROM node:18-alpine3.17 ENV PORT=80 ENV GRAPHQL_SCHEMA_PATH "./schema.graphql" WORKDIR /app COPY --from=build /app/dist /app/dist COPY --from=build /app/node_modules /app/node_modules COPY --from=build /app/package.json /app/package.json COPY --from=build /app/schema.graphql /app/schema.graphql COPY --from=build /app/.env /app/.env EXPOSE 80 ENTRYPOINT [ "node" ] CMD [ "dist/main.js" ] ビルドステージから必要な資材のみコピーする コード
28. クロスアカウントレプリケーションを使ったECR運⽤ 2 8 コード
29. クロスアカウントレプリケーションを使ったECR運⽤ 2 9 指定したタグを開発⽤ECRから取得 指定したタグを付与して本番⽤ECRへpush
30. NestJS(GraphQL)のTips 3 0
31. GraphQLスキーマ開発体制 3 1 GraphQLスキーマ定義の開発⼿法は2つ コードファースト スキーマファースト
32. GraphQLスキーマ開発体制 3 2 スキーマファーストを採⽤ ‧スクラムを採⽤しており、スプリント内で機能を完成させたい  ‧スキーマが遅れると、その分フロント側の開発着⼿が遅れる ‧フロントエンド/バックエンドどちらでもスキーマ変更の提案ができる  ‧コードファーストだとスキーマがバックエンド側の実装に引き込まれる ‧スキーマで⼿戻りが発⽣しても、ペアプロで即座に解消できる少⼈数体制
33. GraphQLスキーマ開発体制 3 3 ‧スキーマ定義は、バックエンド/フロントエンドで議論が起きやすい  ‧命名規則, レスポンス, etc.. ‧PRベースの⾮同期レビューをせず、同期でレビューを実施
34. src ᵓᴷᴷ auth/ // ೝূೝՄ(AuthGurad࣮૷) ᵓᴷᴷ handlers/ // ΠϯλϑΣʔε૚ │ .. │ └── handler.module.ts // ΠϯλϑΣʔε/υϝΠϯ/ΠϯϑϥΛ1ͭͷϞδϡʔϧʹ͢Δ ᵓᴷᴷ domains/ // υϝΠϯ૚ ᵓᴷᴷ infrastructures/ // Πϯϑϥ૚ ᵓᴷᴷ app.module.ts // ϧʔτϞδϡʔϧ ᵓᴷᴷ main.ts // ΤϯτϦϙΠϯτ ᵓᴷᴷ graphql.ts // ࣗಈੜ੒ϑΝΠϧ └── utils/ // ϩΨʔઃఆͳͲ ソース構成 モジュール分割をせず、全てhandler.module.tsにまとめる 3 4
35. import { Module } from '@nestjs/common'; import { GetSessionUseCase } from 'src/domains/get-session-use-case'; import { PrismaClientProvider } from 'src/infrastructures/prisma-provider'; import { SessionRepository } from 'src/infrastructures/session-repository'; import { SessionResolver } from './resolvers/session-resolver'; @Module({ imports: [], providers: [ SessionResolver, GetSessionUseCase, SessionRepository, PrismaClientProvider, ], }) export class HandlerModule {} ソース構成 コード 3 5
36. 認証‧認可実装 3 6 認証にはLINEログインを利⽤ τʔΫϯͷछྨ ܗࣜ ݕূํ๏ *%
    5PLFO +85 )4 ϔομʔϖΠϩʔυ෦ΛνϟϯωϧγʔΫϨοτͰ)."$ 4)"ϋογϡΛͱΓݕূ "DDFTT
    5PLFO ೚ҙจࣈྻ ݕূΤϯυϙΠϯτΛఏڙ ࠾༻
37. AccessToken検証⽅法 3 7 export const verifyAccessToken = async ( accessToken: string, ): Promise<VerifyAccessTokenApiResponse> => { const res = await Axios.request<VerifyAccessTokenApiResponse>({ method: 'get', url: `${LINE_API_BASE_URL}/verify?access_token=${accessToken}`, }); if (res.data.client_id !== LINE_CHANNEL_ID) { throw new LineApiVerifyAccessTokenInvalidClientIdError(accessToken, res); } if ( res.data.expires_in <= 0 // LINEΞΫηετʔΫϯਪ঑ݕূࣄ߲ ) { throw new LineApiVerifyAccessTokenExpiredError(accessToken, res); } return res.data; }; コード
38. AccessToken検証⽅法 3 8 以下のライブラリを利⽤ ‧passport-http-bearer ‧@nestjs/passport @Injectable() export class LineHttpBearerStrategy extends PassportStrategy( Strategy, lineStrategy, ) { private readonly logger = new Logger(LineHttpBearerStrategy.name); async validate(bearerToken: string): Promise<UserPro fi le> { try { await Line.verifyAccessToken(bearerToken); const userInfo = await Line.getUserInfo(bearerToken); return { sub: userInfo.sub, }; } catch (e) { this.logger.log('UnauthorizedRequest', { bearerToken: bearerToken, error: e, }); throw new UnauthorizedException(); } } } @Injectable() export class GraphqlLineAuthGuard extends AuthGuard(lineStrategy) { getRequest(context: ExecutionContext) { const ctx = GqlExecutionContext.create(context); return ctx.getContext().req; } } コード コード
39. AccessToken検証⽅法 3 9 @UseGuradsアノテーションを使⽤して、GraphQLに認可処理を追加 @UseGuards(GraphqlLineAuthGuard) @Query(() => SessionConnection) async sessions( @CurrentUser() user: UserPro fi le, @Args() option?: unknown, ): Promise<SessionConnection> { try { this.logger.log('CalledSessions', { option: option, user: user, }); … コード
40. JWT(HS 25 6 )の検証⽅法 4 0 export const jwtHs256Strategy = 'jwtHs256Strategy'; @Injectable() export class JwtStrategy extends PassportStrategy(Strategy, jwtHs256Strategy) { constructor() { super({ jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(), secretOrKey: LINE_CHANNEL_SECRET, algorithms: ['HS256'], }); } (தུ) } passport-jwtを利⽤ コード
41. CORS対応 4 1 GraphQLエンドポイントのCORS対応。簡単！ async function bootstrap() { (தུ) app.useGlobalFilters(new GlobalExceptionFilter()); app.enableCors({ origin: CORS_DOMAIN, // ։ൃ͸*ʹ͓ͯ͘͠ͱϑϩϯτଆͷ։ൃָ͕ methods: ['POST', ‘OPTIONS'], // Access-Control-Allow-Method allowedHeaders: ‘authorization,content-type', // Access-Control-Allow-Headers }); await app.listen(port); } コード
42. ⾼い負荷が予測されるQuery対策 4 2 query a2 { a: sessions( fi lter: {}) {nodes {id title speakers {id name } date start end }} b: sessions( fi lter: {}) {nodes {id title speakers {id name } date start end }} … h: sessions( fi lter: {}) {nodes {id title speakers {id name } date start end }} } 多数のクエリ1回で送信可能。サーバーに負荷を与える攻撃にもなり対策が必要。
43. ⾼い負荷が予測されるQuery対策 4 3 Query complexityを計測し、複雑度が100以上のクエリはレスポンス を返却しないようにした // 1ճͷ৔߹ {“level”:”info","message":"QueryComplexity","params":{"complexity":10},...} // 8ճҰׅΫΤϦͷ৔߹ {“level”:”info”,"message":"QueryComplexity","params":{"complexity":80},...} // 12ճҰׅΫΤϦͷ৔߹ {“level”:”info","message":"QueryComplexityOver","params":{"complexity":120})...} コード
44. Field Suggestion対策 4 4 { "errors": [ { "message": "Cannot query fi eld \"sssions\" on type \"Query\". Did you mean \"sessions\"?", "extensions": { "code": "GRAPHQL_VALIDATION_FAILED" } } ] } フィールドのエラーメッセージでスキーマが推測されてしまう。 脆弱性に繋がるため、エラーハンドリングをする。
45. Field Suggestion対策 4 5 @Module({ controllers: [HealthCheckController], providers: [ComplexityPlugin], imports: [ AuthModule, GraphQLModule.forRoot<ApolloDriverCon fi g>({ (தུ) formatError: (formattedError: GraphQLFormattedError) => { logger.log(`CatchException`, formattedError); if ( formattedError.extensions?.code === ApolloServerErrorCode.GRAPHQL_VALIDATION_FAILED ) { return new BadRequestException(); } (தུ) )} // Ϩεϙϯε { "errors": [ { "response": { "message": "Bad Request", "statusCode": 400 }, "status": 400, "options": {}, "message": "Bad Request", "name": "BadRequestException" } ] } コード
46. ロガー 4 6 要件 ‧ユーザー毎/リクエスト毎に処理動向が追えれば良い 簡易に⽤意できるCloudWatch Logsを活⽤ ‧ライブラリは、成熟しているwinstonを利⽤  ‧pinoがパフォーマンス的には良いらしい…要検証 ‧Node.jsのAsyncLocalStorageに以下の情報を格納し、JSONで吐き出すように  ‧x-amzn-trace-id(ALBのリクエストに⼀意な値)  ‧LINEのuserId  ‧サービスのuserId コード
47. PrismaのTips 4 7
48. (前提) MySQLの設定 4 8 [mysqld] character_set_server=utf 8 mb 4 sql_mode=TRADITIONAL,ONLY_FULL_GROUP_BY general_log= 1 log_output=TABLE slow_query_log= 1 long_query_time= 2 autocommit= 0 // オペレーション上不安要素が多いため transaction_isolation=READ-COMMITTED // サービス性質上最適な分離レベル local-in fi le= 1 コード
49. Prismaの接続先を動的に変更する 4 9 DATABASE_URL= mysql://$DB_USERNAME:$DB_PASSWORD@$DB_HOST:3306/$DB_DBNAME SecretMangerの値を動的に連結して、CDK経由でタスク定義の環境変数に設 定できない NG!
50. Prismaの接続先を動的に変更する 5 0 コンテナビルド時に接続先情報を.envにハードコードするか？ ‧環境ごとにコンテナイメージが必要になる  ‧クロスアカウントレプリケーション不可になる ‧コンテナイメージがクレデンシャル化する => 解決策: dotenv-expandを使う
51. Prismaの接続先を動的に変更する 5 1 import * as dotenv from 'dotenv'; import { expand } from 'dotenv-expand'; const env = dotenv.con fi g(); expand(env); DATABASE_URL= mysql://$DB_USERNAME:$DB_PASSWORD@$DB_HOST:3306/$DB_DBNAME dotenv-expandは、.envに書いた環境変数を動的に展開して新しい環境変数 に再設定してくれる コード コード
52. Prismaを使った実装例 5 2 登壇者の名前から、セッション⼀覧を引く SQLが必要 登壇者の名前から、セッション⼀覧を知りたい
53. スキーマを定義する 5 3 交差テーブル
54. Prismaのモデル定義を書く 5 4 model Sessions { sessionId String @id @map("session_id") title String @map("title") date String @map("date") start String @map("start") end String @map("end") createdAt DateTime @default(now()) @map("created_at") updatedAt DateTime @default(now()) @map("updated_at") @@map("sessions") } コード
55. Prismaのモデル定義を書く 5 5 model SessionSpeakers { sessionId String @map("session_id") speakerId String @map("speaker_id") createdAt DateTime @default(now()) @map("created_at") updatedAt DateTime @default(now()) @map("updated_at") @@id([sessionId, speakerId]) @@map("session_speakers") } コード
56. Prismaのモデル定義を書く 5 6 model Speakers { speakerId String @id @map("speaker_id") name String @map("name") createdAt DateTime @default(now()) @map("created_at") updatedAt DateTime @default(now()) @map("updated_at") @@map("speakers") } コード
57. レスポンスを想像し、SQLを書いてみる 5 7 SELECT sessions.session_id AS sessionId, sessions.title AS title, sessions.start AS start, sessions.end AS end, sessions.date AS date, session_speakers.speaker_id AS speakerId, speakers.name AS name FROM sessions LEFT JOIN session_speakers ON sessions.session_id = session_speakers.session_id LEFT JOIN speakers ON session_speakers.speaker_id = speakers.speaker_id WHERE speakers.name = 'speakerName1'; { "data": { "sessions": { "nodes": [ { "id": "session1", "title": "ηογϣϯλΠτϧ1", "speakers": [ { "id": "CM001", "name": "speakerName1" } ], "date": "2023/07/07", "start": "13:30", "end": "14:10" } ] } } }
58. Prsimaで実装する場合2つの⽅法 5 8 前述ようなデータを取得する⽅法は以下の2つの⽅法がある。 ‧Relationsを使う⽅法 ‧queryRawを使う⽅法(ORM感はないが…
59. Relationsを使う 5 9 Relationsは、Prisma スキーマ内の 2 つのモデル間の接続する⽅法 ‧ 1 : 1 ‧ 1 :N ‧N:M
60. Relationsを使う 6 0 model Sessions { sessionId String @id @map("session_id") title String @map("title") date String @map("date") start String @map("start") end String @map("end") createdAt DateTime @default(now()) @map("created_at") updatedAt DateTime @default(now()) @map("updated_at") sessionSpeakers SessionSpeakers[] @@map("sessions") } コード
61. Relationsを使う 6 1 model SessionSpeakers { sessionId String @map("session_id") speakerId String @map("speaker_id") createdAt DateTime @default(now()) @map("created_at") updatedAt DateTime @default(now()) @map("updated_at") sessions Sessions @relation( fi elds: [sessionId], references: [sessionId]) speakers Speakers @relation( fi elds: [speakerId], references: [speakerId]) @@id([sessionId, speakerId]) @@map("session_speakers") } コード
62. Relationsを使う 6 2 model Speakers { speakerId String @id @map("speaker_id") name String @map("name") createdAt DateTime @default(now()) @map("created_at") updatedAt DateTime @default(now()) @map("updated_at") sessionSpeakers SessionSpeakers[] @@map("speakers") } コード
63. Relationsを使う 6 3 -- AddForeignKey ALTER TABLE `session_speakers` ADD CONSTRAINT `session_speakers_session_id_fkey` FOREIGN KEY (`session_id`) REFERENCES `sessions`(`session_id`) ON DELETE RESTRICT ON UPDATE CASCADE; -- AddForeignKey ALTER TABLE `session_speakers` ADD CONSTRAINT `session_speakers_speaker_id_fkey` FOREIGN KEY (`speaker_id`) REFERENCES `speakers`(`speaker_id`) ON DELETE RESTRICT ON UPDATE CASCADE; マイグレーションを実⾏すると、外部キー制約が作成される
64. Session⼀覧を取得する実装 6 4 const records = await this.prismaClient.$transaction((tx) => tx.sessionSpeakers. fi ndMany({ select: { speakerId: true, sessions: { select: { sessionId: true, title: true, start: true, end: true, date: true, }, }, speakers: { select: { speakerId: true, name: true, }, }, }, where: { speakers: { name: speakerName, }, }, }), ); スキーマ定義から型が⽣成され、右図の ように、補完を効かせながら取得したい 項⽬を選択できる 補⾜: selectでもautocommit= 0 の場合、 トランザクションが残ります。 BEGIN~COMMITが発⾏が必要なため $transactionをつけています。 参考
65. Transactionはデフォルトタイム設定に注意 6 5 const records = await this.prismaClient. $transaction( async (tx) => { // TODO }, { maxWait: 2000, // default timeout: 20000, // default: 5000 }, ); 5秒以上かかり、例外にしたくないクエリ には設定が必要
66. Relations発⾏されるSQL 6 6 本実装で、データ取得関わるSELECTは基本的に3つ 1 . SessionsとSpeakersをJOIN、SpeakerNameをWHEREで指定 => sessionIdとspeakerIdを取得 2 . sessionsテーブルへ、1.のsessionIdを指定して、レコード取得 3 . speakersテーブルへ、1.のspeakerIdを指定して、レコード取得 2と3はPK検索だが、3つのテーブルをJOINして、データを取得しているわけで はない。 チューニングする際には、generallogの確認が必須
67. Relationの問題点 6 7 Relationの問題点 ‧発⾏されるクエリがわかりにくい ‧少し冗⻑なクエリが発⾏される => チューニング状況などで、決まったクエリを実⾏したい場合、queryRawを利⽤
68. queryRawを使う 6 8 問題点 ‧type safeではない  ‧Number型だと思っていたら、BigInt型でJSONパースで例外になることもあった await tx.$queryRaw<SessionRecord[]>`SELECT * …`; 特徴 ‧``で括ったSQLで、引数はプリペアードステートメントになり実⾏  ‧意識せずインジェクション対策済み
69. queryRawを使う 6 9 await this.prismaClient.$transaction( async (tx) => { return await tx.$queryRaw<SessionRecord[]>`SELECT * … FROM sessions LEFT JOIN session_speakers ON sessions.session_id = session_speakers.session_id LEFT JOIN speakers ON session_speakers.speaker_id = speakers.speaker_id ${ speakerName ? Prisma.sql`WHERE speakers.name = ${speakerName}` : Prisma.sql`` };`; }); `; }, ); コード 引数にする場合、Prismaのテンプレートリテラルが必要 (インジェクション対策になる)
70. queryRawUnsafeを使う 7 0 問題点 ‧セキュリティ(インジェクション)リスクがある await tx.$queryRawUnSafe<SessionRecord[]>`SELECT * …`; 特徴 ‧動的にSQL⽣成する場合、queryRawだと出来ないケースがあります
71. queryRawUnsafeを使う 7 1 const getSpeakerQuery = `SELECT speaker_id FROM speakers WHERE name like ?`; // ?͕ϓϦϖΞʔυεςʔτϝϯτʹͳΓɺΠϯδΣΫγϣϯରࡦ const(தུ) const res = await this.prismaClient.$transaction(async (tx) => { // ?ʹϚοϐϯά͞ΕΔbindValues഑ྻೖΕΔ greturn await tx.$queryRawUnsafe(execQuery, ...bindValues); });
72. queryRawのtype safe問題 7 2 Prsimaはスキーマ定義とマイグレーションが強い反⾯、クライアント側の制限 が多い。 そこで、prisma-kyselyと⾔う選択肢。 Kysely (キーセーリー) は、型安全でオートコンプリート対応なTSのSQLクエリ ビルダ。Knex.jsのインスパイア。
73. queryRawのtype safe問題 7 3 そもそもの話になってしまうが、prismaのクライアントを使わず、kyselyのク ライアントをprismaのスキーマから⽣成
74. kyselyでSQLを書いた場合 7 4 const records = await db .selectFrom('sessions') .select([ 'sessions.session_id', 'sessions.title', 'sessions.start', 'sessions.end', 'sessions.date', ]) .leftJoin( 'session_speakers', 'sessions.session_id', 'session_speakers.session_id', ) .select(['session_speakers.speaker_id']) .leftJoin( 'speakers', 'session_speakers.speaker_id', 'speakers.speaker_id', ) .select(['speakers.name']) .where('speakers.name', '=', speakerName) .execute(); コード 返却される値が型安全 (queryRawで⾒落としがち)
75. その他でやって良かったこと 7 5
76. データベースへのデータ投⼊ 7 6 データベースへデータ投⼊要件 ‧マスターデータはお客さんのCSV  ‧CSVの形式はSJIS ‧過去データにも変更が⼊るため、都度truncateとimportが必要  ‧データ投⼊はMySQL LOAD DATA LOCAL INFLEを利⽤
77. データ投⼊スクリプトにはzxを利⽤ 7 7 DBへのデータ投⼊スクリプトにbashではなく、google/zxを活⽤ google/zxは、Node の child_process のラッパー で、$で囲んで shell コマンドを簡単に実⾏できる const result = await $`ls -al`; ‧コマンドラッパーが書きやすい ‧nodeの機能/記法が使える  ‧⾮同期IO  ‧try catch ‧複雑になってきたら、TypeScriptに移⾏しやすい ‧対話型機能がユーテリティとしてあり、よくわるy/N実装の⼿間が少ない
78. データ投⼊スクリプトにはzxを利⽤ 7 8 ⾮同期IOで複数csvを、nkfでSJIS->utf変換する await Promise.all( COMMON_CONVERT_FILE_NAMES.map(async ( fi leName) => { await $`nkf -w -Lu ${path.join( CSV_PATH, COMMON_DIR_NAME, fi leName, )} > ${path.join(TMP_PATH, fi leName)}.utf8`; }), )
79. さいごに 7 8
80. 開発を通して感じたこと 7 9 ‧NestJSとGraphQLの構成は成熟している  ‧豊富なドキュメントと実装例  ‧攻撃に対する対応策  ‧認証/認可周りもライブラリが充実しており、⼿軽に実装できる ‧GraphQLのDSLでフロント/バックエンドでスキーマ駆動開発が捗る ‧Prismaを使っていて、意図通りのクエリが作れないケースは少ない(詰まない)  ‧(課題) 現状の状態だとリポジトリを跨ぐトランザクション要件に弱い  ‧(課題) queryRawに頼ると型安全性で問題あり、クエリビルダへ変更検討   ‧(対策) prismaのマイグレーションと型安全両⽅取りたい場合、マイグレー ションはprismaでクライアントはkysely構成もあり
81. 最後に 8 0 ご清聴ありがとうございました github.com/shuntaka 9576 /devio 2 023 -nest 他に気になる点や、サンプルコードが動作しない場合 は、以下のリポジトリでissueを起票して頂ければ、 可能な限り対応させて頂きます。
82. 参考⽂献 8 2
83. 参考⽂献 8 3 ‧[Prismaの各実装と実際に発⾏されるSQLを確認してみる](https://zenn.dev/shuntaka/scraps/ 8 3 9 f 1 9 3 6 2 0 0 0 0 6 ) ‧[Prisma](https://www.prisma.io/docs/concepts) ‧[NestJS](https://docs.nestjs.com/) ‧[PrismaのJOINの挙動を観察](https://qiita.com/masayasviel/items/ 5 fa 974 4 ac 4 5 d 846 9 0 3 a 9 ) ‧[kysely.dev](https://kysely.dev/) ‧[AsyncLocalStorage](https://nodejs.org/api/async_context.html) ‧[LINEログイン v 2 . 1 APIリファレンス](https://developers.line.biz/ja/reference/line-login/)
84. Special Thanks 8 4 ‧otasさん(https://dev.classmethod.jp/author/ota-seiji/) ‧⻄⽥将幸さん(https://dev.classmethod.jp/author/nishida-masayuki/) 技術的なご相談させて頂いた⽅ありがとうございます！ ‧Satoshi Notoさん(https://dev.classmethod.jp/author/noto-satoshi/) ‧佐藤智樹さん(https://dev.classmethod.jp/author/sato-tomoki/)