Akka HTTP introduction

1. introduction

元ネタ: 1. Introduction・AkkaHTTP

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 を利用している)

Next:

Using Akka HTTP