本投稿、始めは、
「要素系の人と会話をしていると、使い易いフレームワークとはなにか？という点で認識が異なっている。」
...と言うようなタイトルの内容を書こうと思っていたんですが、
前回の投稿と、以下をみて、チョット内容を変えようと思いました。
いやね、要素系の人って、RFCとか読んで、そのまま実装して、仕事終わった。とか思ってねぇ？って、RFC自体を読んで思ったりすることが多いんですよね（ある意味、仕様が正義で、実装は"刺し身たんぽぽ"。みたいなモノの考え方）。
しかし、実際は（、例えば）、SAML2.0を見ても、使われているプロファイルって、構築 ＆ 実装がし易いプロファイル部分を抜いて使ってるダケだったりするので。
だから、最近、色々なOAuth2 / OIDC拡張がバンバン出て来ていますが、コレ等を見ていて、コレ流行らねぇんじゃねーノー？等と思ったりする訳です（そして、今回のコンテンツのポイントは、要素系の界隈でもコレをちゃんと理解している人が居るという話です）。
...という事で、使い易いフレームワークやAPIを開発する事の重要性は昔から高い訳ですが、その「使い易いフレームワークやAPI」って結局の所どんな感じのモノなのか？と言えば、
前回、書いたようなモノで、こう言ったモノを開発するには、
- ランタイム・フレームワークでは機能の仕様＆実装の模倣。
- クラス・ライブラリでは著名なデザインパターンを使用する。
などの方法しかありません。
（新規の仕様＆実装を捻り出すのは、カナリ難易度の高い仕事だと思いますし、ソモソモ、そのような機会に恵まれるケースも少ないと思いますが、その昔、2010年以前、自宅サーバとTCP/IPのソケット通信プログラミングをやり始めた頃、オレオレWebSocket実装を妄想していたこと等もあるので、"
必要な要件を満たした上で、頑張りゃ、出来るっしょ。"などと思ったりもします。）
これは、
機能差のある開発基盤でも、結局は同じだと思っています。
また、フレームワークやAPIの設計・実装には
STPの考慮が重要だと思っていていて、
汎用認証サイトで、「ASP.NET Identity の Community STS」を使用しなかった経緯などもコレに合致します。
前述のCommunity STSは、「特定のAuthZ / AuthNを使用し、Clientにお決まりの認証や、認証 / 認可の処理を実装するには十分。」ですが、「カスタマイズされた複雑なプロファイルに対応する実装を行うには不十分。」です。また、後者は、ニッチである分、模倣が難しいので、自身で考えなければいけない範囲も広いと思います。
一方で、API Gateway系は大規模エンプラでは必須コンポーネントだと思うんですが、慣れれば連携コード書く事の何が大変なの？と、なって逆に重たくなる気もします（JWTをガッツリ処理できるライブラリさえ持ってれば難しいことは無いと思ったりしますが、まぁ、JWT自体の理解とライブラリの仕様理解が、フツーは難しいんだろうなぁ。...とは思います）。
...と言うことで、纏めると、使いやすいフレームワークの開発に必要なのは、基本は模倣、そして、新しい部分の創造には、模倣から得た知識と、対象となるセグメントに何がフィットするか？の仕様決定力が必要。ということですね（ある意味、"累積的イノベーション"なのかもしれません）。
トップページ
お知らせ
開発基盤部会
使いやすいフレームワークって、どうやって開発するの？
