[翻訳]EMPEX NYC Conference 2018 (Elixir/Erlang/BEAM): Keynote(Dave Thomas)
[翻訳]EMPEX NYC Conference 2018 (Elixir/Erlang/BEAM): Keynote(Dave Thomas)
下記動画の内容のメモと所感
Attention
英語とElixirの学習用メモなため、解釈に誤りがある可能性があります。
この内容は参考程度に押さえて基本的に動画を参照してください。
TL; DR
現状のElixir/Phoenixのアーキテクチャに対しての下記の発表となる。
問題提議
その解決方法の提案
解決方法は下記の通りの提案となる
- 考え方：Component Structure
- 実装：Component / Noddy(発表内にて開発中と言及。2018/6/3時点で未公開)
Content
Problem
知っての通りElixir/PhoenixはErlangとRailsを元に作成されている。
ただ、いくつかの良くないところも継承してしまっているのが現状だ。
Naming Application
Applicationという名称だが、Erlangからこの名称は持ってきたが失敗だ。
様々な意味を包括していて結局は何を指しているかがわかりにくい
Dupplication Configuration
コンフィグを他のApplicationにも持たせなければならない。
上記の例で述べるとPaymentMakerのコンフィグをAppOne/AppTwoに持たせないとならない。
もちろん行いたいのはPaymentMakerにのみコンフィグを持つことだ。
Dog food GenServer
GenServerの実装は１つのModuleに３つの内容を含んでいる
APIServerImplementation
わかりにくい。俗に言うdog food、つまりゴチャ混ぜなコードだ。
14:36
Bad Directory Design
左がRailsで右がPhoenixだ。
ほぼ同じ構成になっている。ただ、なんでlib？
wooble.exなんて大抵のprojectではhello worldが書いてあるだけなんじゃないか？
無駄が多すぎる。
Solution
New Naming Application
Component structureでは下記のように提議していきたい。
Library…stateを持つようなprocessがないComponent…stateを持つようなprocessがあるAssembly…configurationであり、Library/Componentを束ねた可搬的なひとまとめ
22:23
23:01
Phoenix Component
上の規則に従うと Phoenix Applicationではなくて、Phoenix Componentとなる。
また、Phoenixにビジネスロジックが何個あるかべきか？０個だ。
Phoenixは純粋なView Layerであるべきだ。
なぜなら PhoenixはInterfaceであり、InterfaceにBusiness Logicは書かないだろ？
ビジネスロジックである実装は更にバックエンドに記述するべきだ。PhoenixはWebServerなんだ。
Component as GenServer
例として１つのGenServerがある。
Componentを使えばこれだけで済む。
内部的にはGenServerをジェネレートしているわけだが、コード量は劇的に減少するだろう。
そして、Componentを使って簡略化しても元のコードからは何も情報は失われていない。
以前としてGenServerであるが、すべてを書く必要がなくなるわけだ。
Component Directroy Design
なんでフォーマット用configファイルである.formatter.exsがtop levelにあって、実装したいメインプログラムであるstack.exsがtop levelにないんだ？おかしくないか？
これで十分だろう。ただ、もしstack.exが複雑になってきたらどうするかって？
そのときになったらサブディレクトリを足してpopper.exやpusher.exのように機能別にファイルを作っていく？違う。私は１つのstack.exに収めたいんだ。
もし、stack.exが複雑になってきたら？componentレベルで分割するんだ。
つまり、数多の小さなcomponentを組み合わせていくわけだ。
これによって、再利用性とメンテナンス性があがるはずだ
How To Deploymnet
現状では、componentで良いデプロイ方法はElixir には存在しない。
紹介しよう！Noddyだ！デプロイメントにはNoddy(NODe Dynamic management)を使う。
（ここでいうNodeはServer上で稼働しているErlangVM上のNodeで、Serverと考える）
- ロギング設定を一元管理
- 並列デプロイ
Node毎にどのComponentをデプロイするかを定義できる
Conclude
Elixirでの開発課題をより簡単にしていきたい。
最終的には誰もが３分でComponentを作成してデプロイでき、そして他の開発者もそのComponentを再利用できる。そんな未来が来るだろう。
所感
GenServerを書いたり読んだりするが、１つのファイルに対してどうしても手続き的なコード量が多くなってしまう問題は以前から感じていただけに、Componentが実用化されればGenServerのコード量という問題点はかなり解決できるのではないか、と感じられた。Component Structureが導入されるためには、現状Noddyも作成中な上、既存のPhoenixの構造から大幅な変更が発生するため、導入障壁と所要時間のハードルが高そうに感じる。