クラウド的なアレ

前回書いた図みたいに、複数のデータソースにアクセスできることを目指したとき、過去にそれが試みてできなかったことを思い出した。 具体的には、どのようにすれば、複数のHibernateの接続先を定義できるのかがよくわからず諦めていた。 が、実は1.8.0からできるようになっている。 Quarkus 1.8 released - Multiple Persistence Units, Micrometer, jbang, GraalVM 20.2 Quarkus: Supersonic Subatomic Java quarkus.io 自分がやりたかったことは "Multiple Persistance Units" と呼ぶらしい。 必要な設定は次の3つ。 1. EntityManagerのクラスのInject時に @PersistenceUnit として他の Persistence Unitと区別可能なデータソースのnameを指定する 2. application.propertiesに PersistanceUnit用のデータソースを指定する 3. 使用するEntityを、Persistance Unit毎にパッケージ分けする 大体のことはここに書いてある。 Quarkus - Using Hibernate ORM and JPA Quarkus: Supersonic Subatomic Java quarkus.io 記載例としては、 1.の例： 1つのPersistance Unitしか使わない場合には不要だった@PersistenceUnitが追加されている。 ここで指定している名前と2.に書くPersistence Unitの名前を合致させる必要がある。 @Inject @PersistenceUnit ( "dummy1" ) EntityManager em; 2.の例： わかりやすさのために自分はdummy1で全て統一してしまっているが、ここには3つの話が載っていると思う。 # dummy1 quarkus.datasource. "dummy1" .db-kind=postgresql quarkus.datasource. "dummy1" .username=

近頃定期的に、RESTful APIいらない、GraphQL最高。 複数クライアント用のBFFをGraphQLにしてOne Size Fit All(OSFA)で対応する！ みたいな話を見聞きすることが度々あってモヤモヤしていた。 特に自分はスキーマ駆動開発でWeb APIを作ってそのスキーマからクライアントサイドのクラスもサーバーサイドのクラスも作り、Web APIを含む開発を楽にするぞ、というあたりの動きを取ることが多いので、それがいらない、あるいはいらないと思われるほどメリットがあまりあるという状況ならキャッチアップ必須と思ったため。 でまあ、雑に言えば、クライアント側の実装の制約がないならBFFはGraphQLでいいのではとは思う状況。 ただし、複数クライアント向けにOSFAで対応するのには現時点では反対。 相当に近しいユースケースならOKだと思いつつ、結局そのBFFにしたGraphQLをアップデートする際になぜ無関係の箇所まで停止の影響を受ける必要があるのか？同じ名称が定義できないなどでネーミングルールが冗長・厳密なものになっていくのはしんどいのではないか、という思いから。 やりたいイメージ的にはこんな感じ。 Data Storeにはなんらか3rd PartyのAPIの取得済み処理結果が入っているとでも思って貰えばOK。 1-4それぞれの口に対していい感じに対処できるのかを見る意味でまず作りを把握しているのが現状。 ソースコードはここに置いた。 tkhm/sandbox-java Contribute to tkhm/sandbox-java development by creating an ac github.com 思ったより簡単というか、ここのページを参考にGradleでプロジェクトを作って、フォルダ構成をちょっと現実っぽく区分けしたところまでが今。 Quarkus - GraphQL Quarkus: Supersonic Subatomic Java quarkus.io ./gradlew quarkusDev で上がってきた後に  http://localhost:8080/graphql-ui/  でGraphQLにクエリを投げられるUIが上がってくる。 今のところ見た感じ、GraphQLを受けるクラスより後ろはRESTful APIの

Pythonの使用歴は、とても長いわけではないが、ほどほどにはプログラムを書いていてそれなりに知っているつもりだった。 が、Python 3.7から重要な変更点としてdataclassというアノテーションが追加されていた点を全く知らなかった。 読んで行くとどうも大抵の場合にはdataclassを使用した方が都合が良いというか、扱いやすく感じるシーンが多いように感じた。 その他にも3.9から入る変更点や、自分の知らないTypingのアノテーションなど。 というわけでサラッと調べたことを振り返ってみる。 データクラス dataclasses — Data Classes — Python 3.9.1 documentation docs.python.org 最近入ったんだろう、そりゃあ見ない顔なわけだ......とか思いたかったがただの自身のキャッチアップ不足。業務で少なくとも2年前から使用している3.7で導入されていた。 雑に使い所と特徴を見ていくと - @dataclasses.dataclassアノテーションをクラスの頭につけるとデータクラスになる - __init__を自分で定義しなくてもフィールドプロパティを書いてあげるだけでOK - dataclass内に関数を定義することはできるし、それ以外にもフィールドの一覧を取得することができたり便利関数が用意されている という感じ。 ちょっと具体例で見てみる。 これが従来型の例。 class MyClass ( object ): def __init__ ( self , filename= "" , changes= 0 ) : self . filename: str = filename self . changes: int = changes dataclassの場合だとこんな感じ。 import dataclasses @dataclasses.dataclass class MyClass : self . filename: str = "" self . changes: int = 0 JavaでいうところのPOJOのような、データの入れ物として使われることが意図されたもの、が公式的に

久しぶりにQuarkusを触ったので少しやる気が出てきた、ということもあり、今だとNativeイメージはどれくらい速いのか、ビルドにはどれくらい時間がかかるのか、と言ったあたりを、環境最新化も兼ねて軽く動かして見てみた。 環境はこんな感じ。（咄嗟にUSキーボードになってしまった時でもハイフンは扱いやすかったので、箇条書きの点をハイフンに置き換えてみたけどどうだろう） - OS: macOS 11.2 - メモリ: 8GB - CPU: 2.7GHz Dual core i5 - Java: openjdk version "11.0.7" OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.7+10) - GraalVM: GraalVM CE 21.0.0 (build 11.0.10+8-jvmci-21.0-b06) - Docker: Docker version 20.10.2, build 2291f61 - Quarkus: 1.11.1.Final 動かしていたサンプルはこの内容。（GraphQLならApolloを使えって話なんだけど......Java育ちなので） Quarkus - GraphQL  https://quarkus.io/guides/microprofile-graphql 比較したのは次のそれぞれの実行時間と、そこから生成された実行ファイルやコンテナイメージを実行した時の起動時間。 ダウンロード時間の差分を入り込ませないようにするため、各コマンドは一度実行し、その後に ./mvnw clean した。（けど、もしかしたらそれだと比較のためのクリアには不十分だったかもしれないがどうだろう） Jar： ./mvnw package -DskipTests java -jar target/microprofile-graphql-quickstart- 1.0 .0-SNAPSHOT-runner.jar Native： ./mvnw package -Pnative -DskipTests ./target/microprofile-graphql-quickstart- 1.0 .0-SNAPSHOT-runner Docker Native： ./

Learning Subscriptionで探していると4つほどQuarkus周りのビデオが公開されていた。 とても短いものだったのだけど、それぞれ知らない内容として得るところがあったのでメモ。 Native Supersonic Subatomic Applications with Quarkus https://rol.redhat.com/rol/app/seminar/exps103-1 他の3つに比してこれのみCaptionが有効。Quarkusとは、と言ったような話。 Quarkusそのものはそれ自体で速いのだけど、Nativeイメージは例として出した最小限のサンプルの場合同じQuarkusで作ったJVMのイメージに比して、メモリ使用量1/10、起動時間は1/50というのを実演していた。 GraalVMあたりが色々面倒で不明確な点が自分には多く感じたのであまり触らないでいたけれど、そろそろいい頃合いかもしれない。 あと、いつもはよくORMにHibernateを使うのだけど、デモの中で見ていたPanacheはかなり良さそうだった。 多分Hibernateと組み合わせで使用して、Panacheの機能によってORMのエンティティがfind()のような機能を持ち、そこでクエリをかけるようなイメージ。 抽象化して便利にしてくれる機能は、具体的に何をどうして裏で何が起きてるのか、がわからないとあまり使いたくないというちょっと保守的な気持ちがあるのだけど、これは使ってみてもいいと思った。 Native Quarkus Images with S2I https://rol.redhat.com/rol/app/seminar/exps207-1 S2Iを使ってQuarkusのNativeイメージを作れるというデモ。 一応使おうとすればS2IはOpenShiftの文脈に限らず使えるし、Dockerfileを吐かせることもできるからこれを何らかのベースに使うといいのかもしれないとはちょっと思った。 デモ内で使われているイメージはQuay.ioで公開されている。関係ないけど、xxx.ioって類のツールとか度々あって、エディター、チャット、メールとかで勝手にリンク作られるの迷惑だからあまり好きなネーミングではないな...... Quay Quay is the best p