フルスタックフレームワークから脱却してマイクロサービスライクにサービスを構築する

## はじめに
Ruby on Railsを代表とするフルスタックフレームワークを利用すれば、
手軽にWebサービスの構築を始める事ができます。
しかし、3年あるいはそれ以上続くWebサービスを構築する際は、フルスタックフレームワークを採用するかどうかは慎重に検討する必要があるでしょう。
ケースバイケースではありますが、マイクロサービスの考え方をフレームワーク・ライブラリ構成に応用すると
メリットがある可能性があります。

## フルスタックフレームワークのデメリット
フルスタックフレームワークは、学習コストが高いですが、Webサービス構築に必要なほとんどあらゆる機能を提供しています。
人気のフレームワークであれば、コミュニティも活発なので、わからないこともググれば解決することがほとんどでしょう。
では、フルスタックフレームワークのデメリットとはなんでしょうか？

1. ロックインされる
 - 一番大きなデメリットといえるでしょう。フレームワークのメジャーバージョンアップがあった場合、それに追随するならば、サービス自体に手を入れる必要があります。  
それ自体はフルスタックフレームワークを採用していなくても起こりえますが、  
例えば言語自体のバージョンアップも含んでおり、ライブラリも最新の構想を取り込んで大きく変更されている。テストも十分に整備されていないといった場合、手も足も出ない状況に陥る可能性があります。  
最近では、Laravel4系からLaravel5系のバージョンアップでかなりの変更がありました。
Laravelは全く違うフレームワークかよくらい変わります。
2. オールインワンである
 - 作ろうとしているサービスが、簡素なものである場合、その構成自体が「大きすぎる」可能性があります。例えば、Web APIを提供し、いわゆる表示する「画面」も必要ないようなサービスである場合、Viewに関するライブラリは必要ないでしょう。しかし、このような不要なライブラリもインストールされてしまいます。また、なんでもできるがゆえに、本来構成を分けるべきサービスが混同されてしまう危険性もあります。
3. 学習コストが高い
 - すでに述べましたが、学習コストの高さが挙げられます。但しこれは、その後得られるメリットを考えるとあまり問題にならないかもしれません

## マイクロサービス
マイクロサービスという考え方自体は、
> システムを複数のサービスの集合体として構成し、サービス相互をRESTful Web APIのようなシンプルで軽量な手段で連携する手法

というように、
サービス構成について述べているだけで、サービス自体を構成するフレームワークやライブラリについては触れていません。
しかし、サービスが依存するフレームワーク・ライブラリに置いてもその考え方を応用することができます。
サービスが依存するものを、「フルスタックフレームワーク」という大きな大きなライブラリにするのではなく、

* Webフレームワーク
* ロガー
* キューイング
* DB

のようにそれぞれの機能別のライブラリに依存するようにすることで、変更に強いサービスを構築できます。  
また、それぞれの機能ごとに、自分がよいと思ったライブラリをチョイスでき、必要最小限のライブラリ構成にできるといったメリットを享受することができます。
[Packagist](https://packagist.org)と[Composer](https://getcomposer.org/)を活用すれば、容易にそれを実現できます。

## おすすめのライブラリ
実際に簡素なWebサービスを作成するにあたりおすすめのものを紹介します。
ここで想定するWebサービスは、HttpRequestを受け付け、DBに受け取った値を保存し、
異常があればログを書いてメールを投げる。そんな簡素なWebAPIを提供するものです。

### Webフレームワーク
[slim/slim](https://packagist.org/packages/slim/slim)

* Routing
* Middleware

など、最低限の機能を提供する薄いフレームワークです。PHP * マイクロサービスで考えると、第一に選択肢に上がるライブラリでしょう

### Logger
[monolog/monolog](https://packagist.org/packages/monolog/monolog)  
Laravelなどのフレームワークも採用している、簡単に使えるライブラリ

### DB
[illuminate/database](https://packagist.org/packages/illuminate/database)
LaravelのDB周りの使い勝手の良さが好き

### Mailer
[swiftmailer/swiftmailer](https://packagist.org/packages/swiftmailer/swiftmailer)
リッチな機能を提供しているMailer

### Config
[illuminate/config](https://packagist.org/packages/illuminate/config)
こちらもLaravelのコンフィグの書きやすさ好きなので

### DI Container
[pimple/pimple](https://packagist.org/packages/pimple/pimple)
シンプルなDIコンテナ。slimフレームワークでも内部的に採用しているが、slimの世界観の中で使わずに、
明示的に指定してサービス内で使ったほうがマイクロサービスぽい気も。

### Queueing
[illuminate/queue](https://packagist.org/packages/illuminate/queue)
特にWebAPIを作っている場合、リクエストを受け付けた後の処理はQueueingしてWorkerに任せたい場面は多い。
ここでもilluminateのパッケージは使いやすいので是非

### Testing
[phpunit/phpunit](https://packagist.org/packages/phpunit/phpunit)
マイクロサービスのメリットを最大限享受するためにもテストは欠かせないでしょう。

## composer.json
以上のライブラリを使うサービスのcomposer.jsonは以下のようになります。

```
{
  "require": {
    "illuminate/database": "*",
    "illuminate/config": "*",
    "illuminate/log": "*",
    "pimple/pimple": "*",
    "swiftmailer/swiftmailer": "*",
    "slim/slim": "*"
  },
  "require-dev": {
    "phpunit/phpunit": "*"
  }
}
```

## おわりに
今回は、フルスタックフレームワークから脱却し、マイクロサービスの考え方をライブラリ選定に活用する具体例を挙げてみました。
新しくサービスを作り始めるときに参考になれば幸いです。

## 参考
* http://kimitok.hateblo.jp/entry/2014/11/09/211820
* http://knowledge.sakura.ad.jp/tech/3377/