Kotlin

仕事の方で、GraphQLをちょっと検討しだした + 個人的にも興味は持っていたので、本格的に触ってみることにしました。 GraphQLをKotlin + SpringBootで利用する方法としては、大きく三つありそうです。 graphql-java-kickstar Domain Graph Service Spring GraphQL の三つがありそうです。どれもコアとしてはgraphql-javaを利用しているため、どのように統合するか？が焦点になっていますね。 Spring GraphQLは、記事の時点(2021/10)では1.0にむけてのマイルストーンを粛々と実装している、という状態です 今回は、graphql-spring-boot-starterを利用してみた感想をば。なお、そもそもGraphQLとは？については、 公式サイトを見ましょう。 <!–more–> セットアップ さて、まずはセットアップ・・・なんですが、実はこのセットアップが大分苦戦しました。なぜかというと、2021/10時点で検索できる記事だと、結構古いパッケージ構造になっているケースが多く、色々動かない・・・というのがあったためです。 現状、 graphql-java-tools graphql-spring-boot-starter graphql-java-servlet といった関連は、すべて graphql-java-kickstart というGitHub Organizationにまとめられているので、こっちを使うのが第一になるかと。 plugins { id("org.springframework.boot") } apply(plugin = "io.spring.dependency-management") dependencies { implementation("org.springframework.boot:spring-boot-starter-web") implementation("com.graphql-java-kickstart:graphql-spring-boot-starter:12.0.0") implementation("com.graphql-java-kickstart:graphql-java-tools:12.0.0") } 最小構成だと↑のような感じになります。バージョンなどはよしなに。 schemaとのマッピング graphql-java-toolsを利用するかしないか、で大分書きかたが異なりますが、基本的にはgraphql-spring-boot-starterを利用する場合は併用しておいた方がよさそうです。 GitHubにも書いていますが、必要なら↓のようなpropertiesを追記します。 graphql: tools: schema-location-pattern: "**/*.graphqls" # Enable or disable the introspection query. Disabling it puts your server in contravention of the GraphQL # specification and expectations of most clients, so use this option with caution introspection-enabled: true さて、マッピングについてはgraphql-java-toolsに準ずるので、Queryに関しては結構シンプルに書くことができます。 ...

去年の12月くらいから、KotlinでAPIサーバーとバッチを含むアプリケーションを業務で作っていました。その感想を書いていきます。 <!–more–> 本題の前に閑話を。世間から１週遅れくらいで、 SEKIRO -SHADOWS DIE TWICE- をプレイしており、この間一周目が終わりました。私は一周目では攻略サイト等は見ないことにしているので、クリアと同時に解禁してみた所、一周目で出したエンドがなかなか厳しい（他のルートより短く、アイテムとかが集まりきらない）ものだと発覚・・・。若干バッドっぽい選択肢ではあったんですが、まさかそういったものだとは思わず。おかげで二週目が厳しいものとなっております。 複数周回がありそうな選択肢だと、バッドっぽいのから選択する癖があるんですが、それが仇となりました。まぁ、二週目を進めている感じ、明らかにPlayer Skillが高まっており、思ったよりも苦戦はしていないのですが。 閑話休題。 環境の前提 今回作ったアプリケーションは、既存のアプリケーションの完全作り直しなんですが、肝心の既存アプリケーションが PL/SQL で出来ており、完全新規に当たっては DDD を試験的に取り入れています。 Middleware/Framework 利用しているMiddleware/Frameworkは次のような感じです。 Spring Boot 言わずと知れた。 Spring Batch バッチを作成する必要があったので MySQL 現場ではだいたいこれのようでした。 Kotlin 今回の主役 jOOQ ORM。Oracleに接続する場合はcommercial licenceが必要なので注意（繋げなかった人） Gradle 大分こっちを選ぶ人が増えた印象 アーキテクチャ Clean Architecture とDDDを併用しています。Clean Architectureは、とりあえず原典に従って分割している感じですが、現状あまり困っていないです。ここについてもいつか書ければ。 プロジェクト構成 Gradleのmulti project構成を利用して、DomainやGatewayなどの依存方向を強制しています。DDDを実践する上で、Domainに余計な依存を入れないことが重要だと思っているので、これは結構おすすめです。プロジェクトは次のように分割しています。 domain usecase api batch infrastructure 依存関係は以下のようになっています。domainプロジェクトは、 test以外に外部依存ライブラリがない という状態になっています。 domain <-- usecase <- api └- batch Kotlinの適用範囲 全部 です。設定がめんどくさくてJavaになっているものも１ファイルくらいありますが、99.9% Kotlinで書いています。 Kotlin + SpringBootの感想 感想と言っても特筆すべきものはなく、あえて言えば 普通 です。Spring自体がKotlin対応を行っているということもあり、実に普通な書き心地です。 ただ、DIをしまくる関係上、関数で済むようなものでもinterfaceにしないといけないので、その点がストレスです。 @Component class Foo(private val bar: () -> String) { fun exec() = bar() + "test" } みたいなクラスがあったとき、関数をDIすることが出来ない（多分）ので、わざわざinterfaceを定義する必要があります。 ...