管理画面の生成におけるopenapiとJDLなどの考察 のバックアップ(No.3)
- バックアップ一覧
- 差分 を表示
- 現在との差分 を表示
- ソース を表示
- 管理画面の生成におけるopenapiとJDLなどの考察 へ行く。
- 1 (2022-05-07 (土) 18:50:21)
- 2 (2022-05-07 (土) 19:36:24)
- 3 (2022-05-08 (日) 03:12:52)
前提条件 †
OpenAPIの定義がある状況で、管理画面を早く正確に作ることがゴールである場合の手法について考察してみる。
管理画面は、ユーザが使うものではないから、デザインはそこそこのレベルがあればいい。
画面までの自動生成であれば、データベースのテーブル作成も範囲に含めてならば、jhipsterがいい感じにCRUDを行える画面作成までやってくれる。
しかし、DBは既存であり、しかもそこには、API経由でしかアクセスできない場合、どのような手法が考えられるだろうか？
まずは半自動でもいいので考える。作業量が減って正確であればいいのだから。
一覧表示系の画面を効率よく作成するパターンについて考える †
アイデアとしては、APIでGET系のレスポンスの構造を解析し、それをJDLで記述するというやり方だ。
JHipsterで生成されたコードの修正箇所は、まずDB関係のコードは不要になるだろうし、 そのDBにアクセスしに行っている箇所を差し替えなくてはならない。
差し替える用のコードは、openapi-generatorでクライアント用のコードを生成したものと差し替える必要がまずはあるだろう。
ここまでが自動生成のほうが早くて、自動化できそうな箇所であろう。
そこまで行ったならば、こんどは、openapi-generatorで生成したコードが外部のAPIから読み込んだデータを、jhipsterで生成したDAOとして取得するように修正する必要がある。
この手法は、おそらく毎回似たような対応で済むだろうから、知見が増えやすいと思う。
新規作成・更新系の画面は、どうだろうか？これは、openapiの定義のメソッドの種類で、POST、PUTのリクエストパラメータを分析して、JDLを作成するというのでどうだろうか？ †
jhipsterで生成したコードのうち、saveメソッドでＤＢを更新しに行っている箇所を以下のもので差し替える作業となるであろう。 差し替えるものは、openapi-generatorで生成したクライアント用コードである。
ここまでが自動生成したコードであり、あとの作業としては、 openapi-generatorで生成したコードが外部のAPIに更新しに行く修正である。
openapiからjdlを生成するツールの要件を考える †
open-apiを解析しjdlを生成するというのを手作業でやると、apiの数が膨大な場合
詰んでしまう。なので何らかのツールがあったらよいということになる。
まず、apiがgetメソッドの場合は、レスポンスを解析してJDLを生成する機能が欲しい。
次にapiがpost、putメソッドの場合は、クエリパラメータを解析してJDLを生成する機能が欲しい。
エンティティが重複してしまう課題 †
APIの定義が、ER図のように正規化されていないのが原因で、
例えばテーブルというかエンティティがAPI1とAPI2でかぶってしまう場合がある可能性がある。
JDLから生成されるのはCRUDのうち１つのメソッドしか対応できない課題。 †
generatorから生成されるのはCRUDのうち１つのメソッドという可能性もある。 提供されているAPIがきれいにCRUDに対応していることは、無い前提で考えていかないといけないだろう。
ただし、対応してそうな場合は、極力対応させたほうがいいとも思える。
解決案 †
生成する画面のコードは、JHipsterのデフォルトではCRUDに対応したものであるが、 それぞれ、GET用、POST用、DELETE用に分けてテンプレートを用意しておき、
生成されたコードを必要に応じてコピーするようにしてみてはどうだろうか？
できれば、JDLを拡張し、各エンティティにメソッドの種別をアノテーションで指定できるように改造する必要があると思う。
改造が難しいのならば、全メソッド用のコードをJHipsterが行い、必要なメソッドのコードをコピーするスクリプトを作るのも代替え案としては有りかと思う
openapi-generatorの調査対象 †
openapiのyamlをパースした後、パラメータについてのコードを生成している箇所とレスポンスを生成している箇所について調査が必要と考える。
懸念 †
このやり方で進めていっても、結局はswaggerで出力される画面の劣化版みたいなものを作るだけになってるのではないだろうか？
結局JHipsterは、データベースのテーブルのCRUD操作ができる画面を生成するのが優れているわけである。なので、もっと本質的な課題は、openapiの定義を、いかにER図に寄せることができるかどうかであろう。
仮説 †
DBに直接アクセスできないプロジェクトがあるという前提ですが、以下の仮説をかんがてみました。
APIで定義されたGETメソッドをJDLに置き換えた世界では履歴テーブル的な構造で定義すると収まりがよい説
理由は、リモートのDBにアクセスできないからといって、ローカルに検索結果を格納していけば、なんか使えそうな情報になったりしないだろうか？という考え。
これまで、ログファイルに何でも書き込んで置けば、あとでAIとかで解析するときにつかえるのでは？という安直な考えでなんでも大量にログに出していたかと思いますが、あらかじめ検索結果の構造がわかっているわけだし、DBに格納してしまえば解析の前処理が不要になる分、データマイニングがはかどるのではないかと思います。
この流れを生むには、これまで外部のAPIを直接たたきに行く仕組みをBFFという中継サーバを経由する実装に置き換える必要が出てくるわけです。
