Akka HTTP introduction
1. introduction
Def:
Akka HTTP モジュールは、「akka-actor」と「akka-stream」の上にフルのサーバサイドと、クライアントサイドのHTTPスタックを実装したもの
フレームワークというよりは、HTTPベースのサービスを提供したり、使ったりするための標準的なツールキット、という立ち位置らしい。
(詳細: Philosophy にて後述)
性質:
オープンなデザイン
同じことをするのに、いくつかのAPIのレベルの選択肢がある(が提供されている)。
「自分の提供したいアプリケーションに最適なレベルのAPIを選んで使ってね。
高レベルで実現するのが辛かったら、低レベルなAPIを使って実現できる可能性があるよ」
とのこと。
ここでいう「高レベル」は「ガチガチに色々揃った、準備されたもの」
「低レベル」は「より生に近く、柔軟性の高いもの」らしい。
なので、低レベルのAPIを選択するということは、コードをより多く書くことが要求されるということとなる。
Philosophy:
アプリケーションのコアを提供するフレームワークではなく (というよりも、むしろ) レイヤーを統合するツールを提供することに明確に焦点を当てて開発されてきた。
X: フレームワーク
O: ライブラリの集合体
フレームワーク
「フレームワーク」というと 結構完成されたもの(フレーム)が前もって作られていて、その提供されたものと、それを自分なりに組み替えるに当たって用意されているサポートを使って、素早く目的ものを作成する というイメージがある (し、実際にそういうものである) 。
ある意味では、フレームワークは、「肉 (flesh) 付け」をするための「骨組み (skeleton)」であり、骨に肉をつけていくことで、アプリケーションが活き活きしてくるものである。
このように、開発を進める前にどのフレームワークを使うかを決めて、
そのフレームワークのやり方に沿って (開発を) 進めていけば、
フレームワークは最高の働きをする (だろう) 。
例えば、ブラウザ越しに使われる web-application などを作る場合には、フレームワークを使うのが賢い選択である。
Akka HTTP の目指すもの
もし、開発しようとするものの「コア」がブラウザインタラクションなものではなく、「特殊で、複雑なビジネスサービス」であったり、「単に REST/HTTP インターフェースを介して世界に発信したいんだ！」という場合には、フレームワークは必要ないかもしれない...
(大道具すぎる、ということ?)
こう言った場合には、アプリケーションのアーキテクチャは、インターフェース層ではなく、"コアにとって意味あるもの" によって決定されるべきである。
また、ブラウザ固有のフレームワーク ( のコンポーネント ) にありがちな
「view のテンプレ化」であったり「アセットの管理」であったり、
「JavaScript や CSS 周りの取り扱い」や
「localization のサポート」、「AJAX のサポート」
といったことの恩恵を受けることは恐らくないだろう (と思われる) 。
Akka HTTP は、「フレームワーク嫌い」 をしている訳ではない。
「フレームワークを選択するのが適切でない場合に (も)
そぐうように」 not-a-framework として作られているのである。
Akka HTTP は HTTP をベースにした
レイヤーの統合を目的として作られている。
なので、通常は Akka HTTP の上にアプリケーションを構築する、という
( フレームワーク的な使い方をされる) ことはない。
他方で、もしフレームワークに沿ったアプリケーションを構築したいのであれば、Play Framework や Lagom をオススメする。
(これらは内部的に、Akka HTTP を利用している)