Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
OpenAPIによるスキーマ駆動開発を実現するための道のり
Search
Cyan
December 12, 2022
Programming
1.3k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
OpenAPIによるスキーマ駆動開発を実現するための道のり
Kotlin Fest Reject Conference 2022 発表資料
Cyan
December 12, 2022
More Decks by Cyan
See All by Cyan
EBMをベースに考えるプロダクト価値最大化 / Product Value Maximization Based on EBM
cho0o0
0
340
VPoEの視点から見た、ヘンリーがサーバーサイドKotlinを使う理由 / Why Server-side Kotlin 2024
cho0o0
1
940
エンジニアリング上の経験を普段のコミュニケーションにも活かせた話
cho0o0
0
220
Hatena DevBlog Meetup #1 LT
cho0o0
0
3.7k
ヘンリーのコミュニケーションスケーリング戦術 ~ミーティング編~
cho0o0
1
300
ファシリテーション勉強会
cho0o0
0
200
Token Ringについて
cho0o0
1
1.4k
仕様ワークショップ
cho0o0
0
130
Introduction to ATDD (ATDD入門)
cho0o0
0
140
Other Decks in Programming
See All in Programming
技術的負債を組織課題として解く-増えすぎたマイクロサービスとの戦い-
reimaru
1
2.6k
仕様駆動開発による爆速プロダクト開発 / Bakusoku Spec Driven Development
kobakei
0
170
Streamlitで実現する自然言語データアプリ開発
ayumu_yamaguchi
1
330
速習iPhone Duo対応
yuukiw00w
2
940
Turning Architecture into Unit Tests in the AI Era (NSSpain XIV)
steliosf
PRO
1
120
パズルゲームの作り方 / how to make puzzle games
kaityo256
PRO
2
260
難しいけど、読めた。- OSSの入口に立った話。
sts11142
0
130
設計次第でAIコードの読む量は減らせる / designing-for-code-reading
minodriven
33
14k
Starting & Sustaining Code-Based E2E Testing for Non-Coding QA Teams( #jasstniigata )
teyamagu
PRO
1
860
App Intentsのビルドプロセスを支える技術
kntkymt
0
500
WebRTC映像をAirPlayに対応させる挑戦.pdf
monolithic_adam
0
330
Agentic Software Factoryに、すごく賢いIF文を。 / super smart IF statement into the Agentic Software Factory.
rkaga
3
1.2k
Featured
See All Featured
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4.2k
Effective software design: The role of men in debugging patriarchy in IT @ Voxxed Days AMS
baasie
1
550
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
1k
Designing for Timeless Needs
cassininazir
1
510
HDC tutorial
michielstock
2
940
Ethics towards AI in product and experience design
skipperchong
2
410
Primal Persuasion: How to Engage the Brain for Learning That Lasts
tmiket
0
490
My Coaching Mixtape
mlcsv
0
340
Bootstrapping a Software Product
garrettdimon
PRO
306
120k
Breaking role norms: Why Content Design is so much more than writing copy - Taylor Woolridge
uxyall
1
430
Building AI with AI
inesmontani
PRO
1
1.3k
Transcript
Copyrights(c) Henry, Inc. All rights reserved. OpenAPIによる スキーマ駆動開 発を実現するため の道のり
張 @shenyu_cyan
Copyrights(c) Henry, Inc. All rights reserved. 自己紹介 略歴 音声認識の会社にて自然言語処理の
R&Dエンジニアとして務めた 後、株式会社ビズリーチへ転職し、複数のサービス開発のリードやプ ロジェクト管理、エンジニア採用などを経験。 2021年からヘンリーに 参画。 StrengthsFinder 1. 学習欲 2. 個別化 3. 包含 4. 最上志向 5. アレンジ
Copyrights(c) Henry, Inc. All rights reserved. アジェンダ • WHY なぜOpenAPIによるスキーマ駆動開発を使うべきと判断し
たのか • Contract-first vs. Code-first • OpenAPI vs. GraphQL vs. gRPC • WHAT サーバーサイドKotlinでスキーマ駆動開発を実現するため の守破離
Copyrights(c) Henry, Inc. All rights reserved. Contract-first vs. Code-first 予約システム
名簿システム 検査報告システム Henry Integration API
Copyrights(c) Henry, Inc. All rights reserved. Contract-first vs. Code-first OpenAPI
Specification (OAS) Kotlin
Copyrights(c) Henry, Inc. All rights reserved. Contract-first vs. Code-first OpenAPI
Specification (OAS) Kotlin e.g. SpringFox / SpringDoc
Copyrights(c) Henry, Inc. All rights reserved. Contract-first vs. Code-first 予約システム
名簿システム 検査報告システム Henry Integration API 外部サービスベンダー様と協業する際のワークフローを 考慮 • 要求の認識合わせ • APIの仕様のフィックス • 各自が実装 • 結合テスト • リリース
Copyrights(c) Henry, Inc. All rights reserved. Contract-first vs. Code-first
Copyrights(c) Henry, Inc. All rights reserved. OpenAPI vs. GraphQL vs.
gRPC • 自動生成ツールチェーン周りのエコシステムが充実し、カスタマイズをそれほど多く行わなくてもいい。 • 外部サービスと連携する部分のプロトコルなので、社内で蓄積されているナレッジはあくまで考慮要素の一つで、世 の中のノウハウの充実さが非常に重要である。
Copyrights(c) Henry, Inc. All rights reserved. gRPC GraphQL OpenAPI
自動生成 First Party GraphQL Code Generator OpenAPI Generator Swagger Codegen 利用ノウハウ 社内にはあるが、世の中で はまだそれ程多くない OpenAPI vs. GraphQL vs. gRPC
Copyrights(c) Henry, Inc. All rights reserved. スキーマ駆動開発を実現する為に 守 破 離
Copyrights(c) Henry, Inc. All rights reserved. スキーマ駆動開発を実現するための守 • OpenAPI Generatorプロジェクトの全体像を把握
• Gradleプロジェクトで使うための設定方法 守
Copyrights(c) Henry, Inc. All rights reserved. OpenAPI Generatorプロジェクト の全体像を把握 2018年、Swagger
Codegen バージョン2.4からフォークされた コミュニティ駆動のOSSプロジェクト その歴史については @NAKANO_Akihitoさんのスライド「平静を 保ち、コードを生成せよ 〜 OpenAPI Generator誕生の背景と 軌跡 〜」をご参照ください。
Copyrights(c) Henry, Inc. All rights reserved. OpenAPI Generatorプロジェクト の全体像を把握 openapi-generator
実行可能なJARプログラム OpenAPI Generatorのインタフェース Gradle Plugin メインの実装
Copyrights(c) Henry, Inc. All rights reserved. OpenAPITools Bazelのプラグイン CLIのNode ラッパー
sbtのプラグイン OpenAPI Generatorプロジェクト の全体像を把握
Copyrights(c) Henry, Inc. All rights reserved. openapi-generator-core openapi-generator openapi-generator-cli openapi-generator-
gradle-plugin sbt-openapi-generator openapi-generator-cli (Node Wrapper) OpenAPI Generatorプロジェクト の全体像を把握 Henryのサーバーサイドアプリは Kotlin+Gradleに統一している為、 こちらだけ意識すれば OK
Copyrights(c) Henry, Inc. All rights reserved. Gradleプロジェクトで使うための 設定方法 openapiプロジェクトを利用した実装モジュール Generatorによって生成されたモジュール
OpenAPIの定義ファイル マルチモジュール構造のプロジェクト ワークフロー 1. spec.ymlにてRestful APIの定義を行う 2. OpenAPI Generator Gradle Pluginを利 用して、Gradleタスクを実行することでエ ンドポイントとDTOのKotlinコードを自動作 成 (openapiモジュール) 3. 実装(app)モジュールにて自動生成され たエンドポイントのインタフェースを継承 し、DTOを活用する
Copyrights(c) Henry, Inc. All rights reserved. Gradleプロジェクトで使うための 設定方法 include("app") include("openapi")
Copyrights(c) Henry, Inc. All rights reserved. Gradleプロジェクトで使うための 設定方法 dependencies {
… implementation(project(":openapi")) }
Copyrights(c) Henry, Inc. All rights reserved. Gradleプロジェクトで使うための 設定方法
Copyrights(c) Henry, Inc. All rights reserved. Gradleプロジェクトで使うための 設定方法 *設定例として抜粋 Gradleプラグインの設定
ジェネレーター設定 テンプレートの設定
Copyrights(c) Henry, Inc. All rights reserved. スキーマ駆動開発を実現するための破 • 自作テンプレートの活用 •
複数の定義ファイルへの対応 破
Copyrights(c) Henry, Inc. All rights reserved. 自作テンプレートの活用 協力会社へ提供するAPIとはいえ、外部向けのAPIサーバーなので、 入力に対するバリデーションが必要。 ソースコード(modules/openapi-generator/src/main/resources/kotlin-server/libraries/ktor)内で確認
したら確かにuseBeanValidationの記述がなかった(非サポートだった)
Copyrights(c) Henry, Inc. All rights reserved. 自作テンプレートの活用 User-defined Templatesを利用すれば、既存のテンプレートを簡単に オーバーライドできる。
• build.gradle.ktsのopenApiGenerate設定に自作テンプレの場所を 指定 templateDir.set("$rootDir/openapi/templates") • テンプレを作成し、オーバーライドしたいファイルのテンプレ名と同 じ名前のファイルとして上記のフォルダに格納する AppMain.kt→AppMain.kt.mustache build.gradle→build.gradle.mustache 弊社では、BeanValidatation以外に、ロギングやデータマスキングのた めに自作テンプレートを活用している。 OpenAPI Generator Gradle Plugin KotlinServerCodegen (org.openapitools.codegen.languag es.KotlinServerCodegen) Default Templates (modules/openapi-generator/src/m ain/resources/kotlin-server/libraries /*.mustache) Kotlin Code (openapi/*.kt)
Copyrights(c) Henry, Inc. All rights reserved. 複数の定義ファイルへの対応 対応するAPIが増えることによって、全てのAPI定義を一つのファイル にまとめることは書きづらさ、メンテナンスしにくさに直結してしまう。 spec.yml
Kotlinコード spec.x.yml spec.y.yml spec.z.yml spec._base.yml
Copyrights(c) Henry, Inc. All rights reserved. 複数の定義ファイルへの対応 • @alexlafroscia/yaml-merge(NPMライブラリ)を使って定義ファイルのマージを行う •
Frontend Gradle Plugin (org.siouan.frontend-jdk11)を使ってGradleタスクとして定義 • GradleタスクopenApiGenerateの依存関係(dependsOn)に定義ファイルマージのGradleタスク を追加 spec.yml Kotlinコード spec.x.yml spec.y.yml spec.z.yml spec._base.yml
Copyrights(c) Henry, Inc. All rights reserved. スキーマ駆動開発を実現するための離 Generator自作の道へ 離
Copyrights(c) Henry, Inc. All rights reserved. Generator自作の道へ Gradleプロジェクトの完全Kotlin DSL化やフレームワークをKtor2へ バージョンアップするために、自作テンプレでバッチを当て続けること
の限界を感じ始めている。 KotlinServerCodegen BeanValidationFeatures AbstractKotlinCodegen DefaultCodegen CodegenConfig KotlinKtor2CodegenKt 完全自作が大変なので、なるべく 既存の基底クラスの恩恵を受け つつカスタマイズしたい (Java Interopが本領発揮)
Copyrights(c) Henry, Inc. All rights reserved. まとめ • PRO: 仕様を簡単に作成でき、それを持って協力会社と認識合わ
せ・同時開発するワークフローを実現できている。 • PRO: カスタマイズ性が高く、既存機能に満足できない場合でも自 作で問題解決を実現できる。 • CON: 幅広い言語と機能へ対応しているため、逆にKotlin関係のメ ンテナンスが遅れたりする。 • CON: ドキュメントを読んでもやり方がわからないケースが少なくな いため、ソースコードまで調べなければいけない場合がある。
Copyrights(c) Henry, Inc. All rights reserved. 医療DX 難しい課題の解決 社会貢献 これらのキーワードが気になる方
一度カジュアルにお話ししましょう We are Hiring ! https://jobs.henry-app.jp/