2024年版 Kotlin サーバーサイドプログラミング実践開発

Transcript

1. 2024年版 Kotlin サーバーサイドプログラミング 実践開発 2024年6月22日 Kotlin Fest 2024 竹端 尚人

2. 自己紹介

3. 竹端 尚人 主にバックエンドエンジニア Twitter: @n_takehata • 2006.04〜 公務員 • 2007.12〜

   SES • 2011.04〜 モバイルゲーム開発(サーバーサイド Kotlinを始める) • 2020.12〜 フリーランス(バックエンド開発、 テックリード、技術顧問など) 概要 現在は主に、クラウド型電子カルテを開発している株式 会社ヘンリーでエンジニアとして従事 Kotlin愛好会というコミュニティの運営もやっています

4. • CEDEC 2018、2019登壇 • Software Design 2019年2月号〜4月号で短期連載 「サーバーサイド開発の品質を向上させる Java→Kotlin移行のススメ」執筆 •

   2021年4月 書籍「Kotlin サーバーサイドプログラ ミング実践開発」出版 • 2023年4月 Techpitにて「Kotlin入門ガイドー言語 思想から特徴・歴史・使いどころまで、まるっと予 備知識がわかる教科書」執筆 • Kotlin Fest 2024登壇 ←New 登壇、執筆

5. アジェンダ 1. 旧Kotlinサーバーサイドプログラミング実践開発 2. 最近のサーバーサイドKotlinで使えるフレームワーク 3. 新Kotlinサーバーサイドプログラミング実践開発 4. まとめ

6. サーバーサイドKotlinで使えるフレームワークの紹介と、 現在ならどういう構成にするかの一案を紹介します

7. 1. 旧Kotlinサーバーサイド プログラミング実践開発

8. 書籍の概要

9. • Kotlinの基礎構文についての学習 • サーバーサイドで使用するフレームワークの学習 (Spring Boot、MyBatis) • 実践的なサーバーサイドアプリケーション(書籍管理シ ステム)の実装 •

   Kotlin製のフレームワークの学習(Ktor、Exposedなど) 書籍の概要

10. Kotlin基礎 ↓ サーバーサイドKotlin基礎 ↓ サーバーサイドKotlin実践(アプリケーション作成) ↓ Extra StageとしてKotlin製フレームワークを知る

11. 書籍内のアプリケーションの全体像

12. • Spring Boot(Webアプリケーションフレームワーク、 DIフレームワーク) • MyBatis(O/Rマッパー) • JUnit(テストフレームワーク) • オニオンアーキテクチャ(アーキテクチャ)

    書籍内のアプリケーションで使用しているフレームワー ク、アーキテクチャ

13. Javaのフレームワークを使用し まずはサーバーサイドKotlin自体の開発に慣れる

14. RepositoryImpl O/Rマッパー (MyBatis) ドメイン オブジェクト Repository Test (JUnit) Service Controller

    (Spring Boot) DI(Spring Boot)

15. 各種フレームワークを現在の考えで 置き換えていきます

16. 2. 最近のサーバーサイドKotlin で使えるフレームワーク

17. • Webアプリケーションフレームワーク • DIフレームワーク • O/Rマッパー • テストフレームワーク

18. • Webアプリケーションフレームワーク • DIフレームワーク • O/Rマッパー • テストフレームワーク

19. Kotlinで使える Webアプリケーションフレームワーク

20. • Ktor • Micronaut • gRPC-Kotlin Webアプリケーションフレームワーク

21. Ktor

22. • JetBrains社が開発しているKotlin製の軽量なWebアプ リケーションフレームワーク • プラグインの機能により、柔軟な機能追加ができ拡張 性が高い • 非同期I/Oをサポートしている 現時点の最終リリース: 2024年5月

    Ktorとは？

23. ルーティング fun Application.configureRouting() { routing { get("/users") { call.respond( User(1,

    "kotlin", "[email protected]") ) } } }

24. プラグインのインストール fun main() { embeddedServer(Netty, port = 8080, host =

    "0.0.0.0") { install(CORS) install(Authentication) }.start(wait = true) }

25. Micronaut

26. • マイクロサービスとサーバーレスアプリケーションの ために設計されたJavaフレームワーク • 高速でメモリ消費の少ない起動を実現している • Ktorの構文での記述もサポートされている 現時点の最終リリース: 2024年6月 Micronautとは？

27. ルーティング @Controller("/hello") class HelloController { @Get @Produces(MediaType.TEXT_PLAIN) fun index() =

    "Hello World" }

28. gRPC-Kotlin

29. • gRPCをKotlinで実装するためのフレームワーク • Protocol BuffersからKotlinのコードを生成し、使うこ とが可能 ※ Webアプリケーションフレームワークという分類とは少 し違うが、Webのインターフェースの一種として紹介 現時点の最終リリース:

    2023年12月 gRPC-Kotlinとは？

30. RPCの実装 class HelloWorldService : GreeterGrpcKt.GreeterCoroutineImplBase() { override suspend fun sayHello(request:

    HelloRequest) { helloReply { message = "Hello ${request.name}" } } }

31. おすすめ

32. None

33. • 軽量で柔軟性の高い設計になっており、アプリケー ションの起動速度も速い • JetBrains社製かつKotlin製で、Coroutinesを使用した 非同期I/Oにも対応しており、Kotlinの特性を活かした 実装もしやすい • REST APIなど、通常のWebアプリケーション・サー

    バーであればベターな選択肢 Ktor

34. • マイクロサービスの1つとして使用する場合は、 gRPC-Kotlinを使用したい(gRPCをマイクロサービスを 実装することは定番) • gRPCを使わない場合は、Micronautも選択肢に上がる その他のフレームワークについて

35. • Webアプリケーションフレームワーク • DIフレームワーク • O/Rマッパー • テストフレームワーク

36. Kotlinで使える DIフレームワーク

37. • Koin • Dagger2 • Kodein DIアプリケーションフレームワーク

38. Koin

39. • サーバーサイド、Android、KMPと様々なプラット フォームで使用可能なKotlin製のDIフレームワーク • シンプルなDSLにより設定が容易 • KSPを使用してアノテーションの解決が行われる 現時点の最終リリース: 2024年4月 Koinとは？

40. モジュールの登録 @Module @ComponentScan("org.koin.kotlinfest") class Module fun main() { startKoin {

    modules(Module().module) } // ・・・ }

41. @Single class UserRepositoryImpl : UserRepository { override fun findUser(id: Int):

    User { // ・・・ } } DI対象の定義

42. コンストラクタでDI @Single class UserService(private val userRepository: UserRepository) { fun getUser(id:

    Int) : User = userRepository.findUser(id) }

43. class UserApplication : KoinComponent { val userService: UserService by inject()

    // ・・・ } フィールドでDI

44. Dagger2

45. • Googleが提供するJavaのDIフレームワーク • もともとSquareが開発していたDagger(1.x)をGoogle がforkして開発している • コンパイル時に全ての解析を行い依存性の解決をする ため、実行時のオーバーヘッドが少ない 現時点の最終リリース: 2024年3月

    Dagger2とは？

46. @Module class RepositoryModule { @Provides fun provideUserRepository(userRepository: UserRepositoryImpl): UserRepository {

    return userRepository } } モジュールの定義

47. @Component(modules = [RepositoryModule::class]) interface ServiceComponent { fun getUserService(): UserService }

    コンポーネントの登録

48. class UserService @Inject constructor(private val userRepository: UserRepository) { fun getUser(id:

    Int): User = userRepository.findUser(id) } コンストラクタでDI

49. class Main { @Inject lateinit var userService: UserService // ・・・

    } フィールドでDI

50. Kodein

51. • Kotlin製の軽量なDIフレームワーク • アノテーションは使わず、シンプルで読みやすいDSLを 提供している • インラインを多用し、高速で最適化されている 現時点の最終リリース: 2024年5月 Kodeinとは？

52. val appModule = DI.Module("appModule") { bind<UserRepository>() with singleton { UserRepositoryImpl()

    } } モジュールの定義

53. class UserService(private val userRepository: UserRepository) { fun getUser(id: Int): User

    = userRepository.findUser(id) } コンストラクタでDI

54. fun main() { val di = DI { import(appModule) }

    val userService: UserService by di.instance() // ・・・ } フィールドでDI

55. おすすめ

56. None

57. • 設定がシンプルで容易になっており、比較的導入しや すい • SpringでのDIに慣れている人にも、読みやすい記述 • @ComponentScanを使った一括でのDI対象の設定も可 能(KSPによりコンパイル時にscanを解決してくれる) Koin

58. • Dagger2、Kodeinともに@ComponentScanのような一括 でDI対象を登録する機能がなく、DI対象を都度全て記述す る必要がある • Dagger2は設定がやや複雑で、学習コストが高い。コンパ イル時に依存関係を全て解決するため、実行速度は速く安 全だが、コンパイル速度が遅くなる可能性がある その他のフレームワークについて

59. • Webアプリケーションフレームワーク • DIフレームワーク • O/Rマッパー • テストフレームワーク

60. Kotlinで使える O/Rマッパー

61. • Exposed • JOOQ • Ktorm O/Rマッパー

62. Exposed

63. • JetBrains社が開発しているKotlin製のO/Rマッパー • SQLライクに実装できるDSL、軽量なDAOという2つの アクセス方法が用意されている • 長い間0.x系が続いていたが、2024年中に1.0になるこ とが予定されている 現時点の最終リリース: 2024年6月

    Exposedとは？

64. // 全カラム指定して定義 object Users : Table() { val id: Column<String>

    = varchar("id", 10) val name: Column<String> = varchar("name", length = 50) val age = integer("age") override val primaryKey = PrimaryKey(id) } // 数値のIDを自動作成 object Users : IntIdTable() { val name = varchar("name", 50).index() val age = integer("age") } // UUIDを自動作成 object Users : UUIDTable() { val name = varchar("name", 50).index() val age = integer("age") } テーブルの定義

65. transaction { // Insert Users.insert { it[id] = "kotlin" it[name]

    = "Kotlin Fest" it[age] = 3 } // Update Users.update({ Users.id eq "kotlin" }) { it[age] = 4 } // Select val users = Users.select(Users.name, Users.age).where { Users.age greaterEq 3 } // Delete Users.deleteWhere{ id eq "kotlin" } } DSLのコード

66. transaction { // Insert User.new { name = "Kotlin Fest"

    age = 3 } // Update user.age = 4 // Select val user = User.find { Users.name eq "Kotlin Fest" }.first() // Delete user.delete() } DAOのコード

67. JOOQ

68. • SQLに近いDSLでのクエリ作成が可能 • テーブルスキーマからのコード生成が可能で、もとも とJavaのO/RマッパーだがKotlinのコード生成にも対応 している • R2DBCによるノンブロッキングI/Oにも対応 現時点の最終リリース: 2024年6月

    JOOQとは？

69. // Insert dslContext.insertInto(USERS) .columns(USERS.ID, USERS.NAME, USERS.AGE) .values("kotlin", "Kotlin Fest", 3)

    .execute() // Update dslContext.update(USERS) .set(USERS.AGE, 4) .where(USERS.ID.eq("kotlin")) .execute() // Select val users = dslContext.selectFrom(USERS).where(USERS.AGE.ge(3)).fetch() // Delete dslContext.deleteFrom(USERS) .where(USERS.ID.eq("kotlin")) .execute() クエリ生成のDSLのコード

70. Ktorm

71. • 純粋なJDBCに基づいたKotlin用の軽量なO/Rマッパー • Kotlin製のサードパーティフレームワーク • 生のSQLに近い形で書ける柔軟なDSLが用意されている 現時点の最終リリース: 2024年5月 Ktormとは？

72. object Users : Table<Nothing>("USERS") { val id = varchar("id").primaryKey() val

    name = varchar("name") val age = int("age") } テーブルの定義

73. // Insert database.insert(Users) { set(it.id, "kotlin") set(it.name, "Kotlin Fest" )

    set(it.age, 3) } // Update database.update(Users) { set(it.age, 4) where { it.id eq "kotlin" } } // Select val users = database.from(Users).select().where { Users.age greaterEq 3 } // Delete database.delete(Users) { it.id eq "kotlin" } クエリ生成のDSLのコード

74. val user = database.sequenceOf(Users).find { it.id eq "kotlin" } if

    (user != null) { user.age = 4 user.flushChanges() } DAOのような実装にすることも可能

75. おすすめ

76. None

77. • テーブルスキーマからのコード生成に対応している • シンプルなDSLで扱いやすく、フレームワークとしても 成熟している • ノンブロッキングI/Oに対応することもできる JOOQ

78. • ExposedはJetBrains社製で、最近改善も重ねられてお り、今後有力な選択肢になる可能性がある • Ktormもシンプルで扱いやすいが、JDBCベースでノン ブロッキングI/Oには対応していない • Exposed、Ktormともにテーブルスキーマからのコード 生成は対応していない その他のフレームワークについて

79. • Webアプリケーションフレームワーク • DIフレームワーク • O/Rマッパー • テストフレームワーク

80. Kotlinで使える テストフレームワーク

81. • Kotest • Spek テストフレームワーク

82. Kotest

83. • Kotlin製のテストフレームワークで、RunnerはJUnitを 使用している • 様々な記述方法が定義されており、目的や好みにあっ た書き方をすることが可能 • データ駆動テスト等、様々な強力な機能を備えている 現時点の最終リリース: 2024年6月

    Kotestとは？

84. class NumberTestByStringSpec : StringSpec({ "isRange:: when value in range then

    return true" { val number = Number(5) number.isRange(1, 10) shouldBe true } }) StringSpec

85. class NumberTestByDescribeSpec : DescribeSpec({ describe("isOdd test") { context("num is odd

    number" ) { val number = Number(1) it("return true") { number.isOdd() shouldBe true } } context("num is even number" ) { val number = Number(2) it("return false") { number.isOdd() shouldBe false } } } }) DescribeSpec

86. class NumberTestByStringSpec : StringSpec({ "isRange:: when value in range then

    return true(using forAll)" { forAll( row(1), row(10) ) { value -> val number = Number(value) number.isRange(1, 10) shouldBe true } } }) データ駆動テスト

87. Spek

88. • BDD形式での書き方が可能なテストフレームワーク • Spek 2.xでは、マルチプラットフォームも念頭に置い て書き換えられている • specificationとgherkinという2つのDSLが用意されて いる 現時点の最終リリース:

    2022年8月 Spekとは？

89. object NumberTest : Spek({ describe("isOdd test") { context("num is odd

    number" ) { val number = Number(1) it("return true") { assertTrue(number.isOdd()) } } context("num is even number" ) { val number = Number(2) it("return false") { assertFalse(number.isOdd()) } } } }) テストコード

90. おすすめ

91. None

92. • JUnitをRunnerとして安定した実行環境がある上で、 用途や好みに応じた記述方法を選択できる • データ駆動テストやプロパティテスティング等、様々 な便利な機能を備えている • アップデートも安定的に行われている Kotest

93. • Spekは2022年8月でアップデートが止まっているた め、現状選択しづらい • Kotest、JUnit以外でKotlinで使えるテストフレーム ワークとして、有力なものは見当たらない状況 その他のフレームワークについて

94. 3. 新Kotlinサーバーサイド プログラミング実践開発

95. サーバーサイドプログラミング実践開発で 作ったアプリケーションを、今ならどういった構成で 作るか？

96. 選択したフレームワークはこちら

97. • Ktor(Webアプリケーションフレームワーク) • Koin(DIフレームワーク) • JOOQ(O/Rマッパー) • Kotest(テストフレームワーク)

98. それぞれのフレームワークの選定理由

99. Ktor

100. • 軽量で柔軟性の高い設計になっており、アプリケー ションの起動速度も速い • Kotlin製で、Coroutinesを使用した非同期I/Oにも対応 しており、Kotlinの特性を活かした実装もしやすい • JetBrains社製で、Kotlinのアップデートへの追随も安 定している Ktorの選定理由

101. • 比較的新しいフレームワークのため、エコシステムや サードパーティのプラグインなどは発展途上 • Springのようなフルスタックフレームワークではない ため、用途に応じて他のフレームワークとの組み合わ せも必要(Spring等に慣れてる人向けの注意点) Ktorの注意点

102. Koin

103. • 設定がシンプルなDSLで容易になっており、学習コスト も低い • マルチプラットフォームに対応し、サーバーサイド以 外との技術スタックの共有が可能 • @ComponentScanを使った一括でのDI対象の設定も可 能 Koinの選定理由

104. • 依存関係をランタイムで解決するため、パフォーマン スに影響が出る可能性がある • 依存関係の追加漏れなどがあっても、コンパイル時に エラーを見つけられないため、実行時のクラッシュに つながる Koinの注意点

105. JOOQ

106. • シンプルなDSLで扱いやすく、フレームワークとしても 成熟している • R2DBCでのノンブロッキングI/Oにも対応している • テーブルスキーマからのKotlinのコード生成が可能 JOOQの選定理由

107. • 生のSQLに近い形のDSLになるため、難しいクエリを書 く際には記述が複雑になる可能性がある • 併せて実装にはSQLの知識が必要 JOOQの注意点

108. Kotest

109. • 様々な記述方法が定義されており、目的や好みにあっ た書き方をすることが可能 • データ駆動テストやプロパティテスティング等、様々 な便利な機能を備えている • JUnitをRunnerとしていて安定した実行環境がある Kotestの選定理由

110. • 様々な記述方法が用意されているので、プロジェクト によって一定の方針決めは必要 • 各Spec(記述方法)ごとに挙動が違う部分があるので、 複数のSpecを使用する場合は注意が必要(ネストした際 の挙動など) Kotestの注意点

111. RepositoryImpl O/Rマッパー (MyBatis) ドメイン オブジェクト Repository Test (JUnit) Service Controller

     (Spring Boot) DI(Spring Boot)

112. RepositoryImpl O/Rマッパー (JOOQ) ドメイン オブジェクト Repository Test (Kotest) Service Controller

     (Ktor) DI(Koin)

113. KtorとKoinを組み合わせて使う場合

114. implementation("io.insert-koin:koin-ktor:3.5.6") koin-ktorを使うことで、Ktorと組み合わせて実装しやすくなる

115. Moduleの定義 val databaseModule = module { single<UserRepository> { UserRepositoryImpl(get()) }

     }

116. Moduleのインストール fun main() { embeddedServer(Netty, port = 8080) { install(Koin)

     { modules(databaseModule) } }.start(wait = true) }

117. Ktorと組み合わせることを想定したフレームワークも 増えていく可能性あり

118. 4. まとめ

119. 技術スタックの現状

120. • Kotlin製のフレームワークで実用的なものもあり、メン テナンスも活発にされている • SpringやJOOQのように、Javaで定番のフレームワー クもKotlin対応がされているものもある • 有力なフレームワークにJetBrains社製のものも含まれ ており、今後の発展にも期待が持てる

121. サーバーサイドKotlinの現状と今後

122. • サーバーサイドの選択肢として、Kotlinが一番人気とい う状況ではない • しかし、やはり言語としての利便性やクオリティは高 く、エコシステムも拡充してきている • サーバーサイド以外の分野も含め、言語としての発展 が期待できる技術であることは間違いない

123. サーバーサイドKotlinやっていきましょう！

124. ご清聴ありがとうございました