はじめに(おことわり)
筆者はGraphQLについては、先週こちらに参加してようやく学習を開始したという入門者です。この記事を書く前に本来ならGraphQLを触って理解を深めてから、というのが筋とは思ってます。とはいえスピード感も重要でパラレルで理解を深めて行くのも一つの手と考えているため、OASGraphについて発表された内容を、浅い理解なりに、むしろ読みながら書きながら理解する感じで、まとめてみようと思います。誤訳・誤解・理解が浅い部分を含む可能性および、あくまで私自身の見解である点ご了承ください。間違いなどありましたらコメント頂けますと幸いです。実際に試した内容などについては別途まとめようと考えており、本記事は文章オンリーです。
StrongLoopが発表したOASGraph
以下の内容はStrongLoopの発表レターを内容に私の理解を加えて書いています。
多くのAPI系の方々が日々チェックされている(?)ProgrammbaleWebにも発表内容の記事が掲載されてるようです。
StrongLoop(買収されたので実質IBM)が、2018/9/24に発表したソフトウェア・パッケージで、TypeScriptで実装されてるようです。
OpenAPI Specification(OAS)に基づいて記述したAPIをGraphQLのインターフェースに変換してくれるそうです。既存のREST(っぽい)API向けにGraphQLのラッパーを作ってくれるものなので、すでにあるREST APIの資産を活かすことができる理解です。
API管理製品であるAPI Connect、フレームワークであるLoopBackは、REST APIを前提としていますが、ここ数年で浮上しているデータセントリックなGraphQLへの対応も並行していくことで、開発者が新しく効率的なAPIデザインが使えるようにするのが目的のようです。
GraphQLが浮上してる一方で多くの企業はREST APIをベースとしているのも事実です。StrongLoop/IBMとしてはREST APIとGraphQLは共存、またREST APIがGraphQLのバックエンドとして機能していくというスタンスのようです。実際GraphQLの勉強会でも、GraphQLがREST APIを全て置き換えることは(少なくとも現時点)できないとされていたので、ケースごとに使い分け・共存して行くというのは共通認識なのかなと思います。
といった背景をもとに、OAS・SwaggerのフォーマットからGraphQLのスキーマを自動生成してくれるOASGraphを開発したようです。
REST APIのリクエストとレスポンスのモデルに対し、実際のREST APIを呼び出すための
resolverを作成し、GraphQLのレスポンスを生成するというマッピングを行うようです。
ここは実際に参考資料先にもあるGetting Startedなどを動かして理解を深めようと思います。。
この手のライブラリは他にも数年前から存在してると思いますが、認証メカニズム、GraphQLの要件を満たすためのサニタイズ・デサニタイズ機能などを提供していることが差別化要素としているようです。この辺りもまず GraphQL自体の理解を深めることでより理解できる内容なので、そちらの勉強も進めます。。
-
認証メカニズム
- セキュアなエンドポイントをviewerにラップしてAPI keyやクレデンシャルをinputとして使うようです。
-
サニタイズ
- GraphQLと互換性のない部分を自動サニタイズするそうです。例えばREST API側で、-, ., ,, :, ;といったGraphQLでサポートされない文字がパラメータやデータ定義に入っていたら除去。
- GraphQLのqueryからREST APIを正しく呼び出すためにデサニタイズし、レスポンスをGrapshQLに準拠した結果を返すために再サニタイズする、といったことを行うようです。
また、このOASGraphを使って、API Guruに登録されているAPIのうちOASとしてwell-formedなAPIについて、上記のような処理を試して概ね成功してるようです。あくまでOASに完全に準拠してないとうまくいかないようなので、既存のREST API資産を活かすためにOASGraphを使うという場合、まずここの定義の見直しから始まる予感もします。
まとめ
GraphQLの学習を始めたばかりの立場では、OASGraphがどれくらい有益になるかまだ書けていない状況ですが、GraphQLの学習と並行しながらOASGraphの理解を今後も深めて行こうと思います。