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