[micronaut] graphQL でunionを使う

micronaut に限らず、GraphQL Java を利用していればSpring boot や他のフレームワークでも同じことができます。
また、groovy で書いてますが、Java / kotlin でも同様のことは実装できます。

schema

こんな感じのschema

ReturnType が、ReturnTypeA と、ReturnTypeB の二つのどちらかとなる場合。

Groovy側ソース

GraphQL インスタンスの作成

それぞれ、schema に合わせた、クラスを作成

最後に、DataFetcher

実行

以下のクエリで、

結果こんな感じ

[micronaut] micronautのLambda上での動作比較

Serverless いいですね! 環境周りの構築から解放され保守や運用の費用が大分抑えられますね。
そんな私、私生活ではSexlessで頑張ってます。費用もGood抑えてます。

今回は、Sexless じゃなくて、Serverless のAWS上のLambdaの動作を確認してみます。

Micronaut上でそれぞれ、groovy, kotlin, kotlin w/ graalで測ってみたいと思います。

Micronaut は、 2.1.3 を利用してます。

groovy と、graal の組み合わせはできません。groovyのリフレクションに、graalVMが完全にサポートしてません。

実装は、簡単にJWTでログイン機能だけを有した処理で、groovy も、kotlinも同様の処理を実装してます。

Quarkus や、Helidon じゃなくて、なぜ Micronautなのか。それは、単純に Grails の知識があるので、Gormなどが使えるので学習が早そうだからです。
それにドキュメントも英語ですが、結構しっかり揃ってるのが良かったです。

kotlin と、 groovy は、 Java 11 (Corretto) で動かしました。
では、動作確認の結果です。

言語/イメージ 速度(cold) 速度(warm) メモリ(cold) メモリ(warm)
groovy 8415.87 ms 35.57 ms 205 MB 206 MB
kotlin 2718.67 ms 64.81 ms 181 MB 182 MB
kotlin w/ graal 342.15 ms 77.35 ms 172 MB 188 MB

cold と warm の差は cold は cold start で、lambda関数が最初に呼ばれる時です。
その後しばらく、warmの状態になっていて、呼び出しが早くなってます。

webアプリ的な観点でいうと、一番最初のlogin時は、cold start で時間がかかる。
その後の動作は、warm状態なので素早い。

しばらく放置してから、再度アプリを触ると遅くなる。という感じになると思います。

利用者から見ると、初回が遅くなるのでネットワークが悪いのかなと感じて携帯を大きく振って電波を拾うような行動を起こす。。。起こさないですし、携帯じゃなくて今はスマホです。

結果は、kotlin w/ graal がcold時のスタートが早いですね。
warm時は、実行毎に少し速度に上下がありますので、warmの結果は参考程度に。

groovyは、言語としては使いやすくてともていいのでチョイスしたいのですが、初回のlogin時だけちょっと時間がかかっても良いというなら選択肢としてはアリだと思いますね。
ただ、今回はとても小さいプログラムで試験したので、アプリケーションが大きくなった時はどうなるか心配はあります。

あと、graal ですが、ドキュメントみながら試行錯誤してやっていたのですが、メモリが10gないと、native-image が作成できなかったです。
CDの自動化の時は、どうするか悩み所ですね。

時間があったら、どのようなプログラムを作ったかも書いておきます。