one_for_allとrest_for_allはtemporaryなプロセスの死で発火しない
再起動戦略one_for_allのSupervisorがいたとして、そこにtemporaryなWorkerとpermanentなWorkerがぶら下がっているとします。
permanentがWorkerがクラッシュすると、temporaryなWorkerが落とされて、両方再起動します。one_for_allなので。
しかしながら、temporaryなWorkerがクラッシュしても、その後何も起きません。temporaryなので。
もし再起動してほしいときは、例えば両Workerをリンクさせて、temporaryのWorkerが落ちたときにpermanentのWorkerに:EXITメッセージが飛ぶようにして、受け取ったpermanentなWorkerはstopするようにしておく、などちょっと工夫が必要。
という学びでした。
umbrellaではRPCしてくれる君をつくろうという話
Elixirのumbrellaは知っていましたが、実際これ分散させて動かすときどうなんのさ、というイメージがぱっとしていなかったのですが、こちらを読んだら腹落ち感が生まれたのでメモ。特にInterface Moduleを切った上でRPCする、というところ。
例えばappとdatabaseという2つのOTPアプリケーションがあったとします。databaseにクエリ投げたりする関数をDatabaseモジュールにつくり、それをappの中で使おうとすると、appはdatabaseに依存している、つまりdepsに{:database, in_umbrella: true}を持つ、ということになります。そうなると、appを立ち上げたいだけなのにdatabaseも立ち上がり、何がマイクロサービスだこんちくしょう、デプロイセパレートリーくそくらえ、というわけです。
上の記事で説明されているアプローチは、appはdatabaseへの依存を持つのではなく、database_interfaceへの依存を持つようにするというものです。database_interfaceはdatabaseへのRPCの方法と、databaseがどこで動いているかを知っている存在です。これを間に挟むことで、それぞれのアプリケーションが個別に立ち上がれるようになるわけです。
+--------------------+ | app | +--------------+ | |-- RPC --| database | | database_interface | +--------------+ +--------------------+
言われてみれば、そうですよねー、というやつでした。
お仕事のVue.jsアプリに入れてみたものたち
最近はカラーミーリピートのフロントエンド開発で生計を立てています。お仕事なのでいろいろ施策があり優先順位があるわけですが、今のチームは自由研究と称して優先順位外のことをしてもほどほどなら許される空気があるので、興味あるツールなどをお試ししています。ということで、その中でいくつか試してみたことと、どうだったかについて書いておきます。なお、バックエンドその他諸々含め、開発の全体感はチームメンバーのスライドで解説されています。
GMOペパボの Rails & Vue.js プロダクト開発の現場 / Rails Developers Meetup 2017 // Speaker Deck
Storybook
コンポーネントのカタログのようなものをつくれることでお馴染みのStorybook。v3.2.0からVueをサポートしはじめたので入れてみています。
きっちり整備すれば、スタイルガイド的にコンポーネントを一覧できて、新しいメンバーが入ってきたときなど、ふむふむ眺めることができるのかなと思います。ただし当初の懸念どおりきっちり整備するのは少々大変で、活用できていない状態です。Storybookにはコンポーネントの単体テスト的な側面があると思っていたのですが、スタイルが崩れるときは「いつの間にかIE11で変な感じになってた」という様なケースがほとんどなので、Storybookによって防げるものでもなく、ちょっと意見が変わりつつあります。StorybookをJestの入力としてSnapshot TestしてくれるStoryshots addonは、残念ながらReact、ReactNative用です。
flow
TypeScriptという選択肢もありましたが、とりあえずやってみようという感じで部分的に入れています。部分的にというのは、SFC以外のlib配下やVuexのモジュールたちのさらに一部です。
これもそれなりにきっちりと網羅的に型を書いていないといまいち恩恵が受けられず、かつVuexの世界はオブジェクトオブジェクトしていてなんだか書きづらいなあという気持ちに。消しちゃおうかというのがイマココです。
Code splitting
https://webpack.js.org/guides/code-splitting/
上記2つは開発効率向上狙い、これはパフォーマンス改善が狙いと違いますが、入れてみたものとして紹介。webpackにコード分割をしてもらっています。import構文で
// before
import Top from 'src/components/pages/Top.vue'
// after
const Top = () => import('src/components/pages/Top.vue')
としていくと、ページ単位に分割されて、必要になったら読み込まれる、というものです。物を売るひとのための管理画面と買う人のための購入画面が同じアプリケーションで提供されていて、お互い不要なコードまで読み込んでいるところをどうにかしたいなあというのが動機です。
bundle-analyzerなどを使うと、分割されたものたちとその中に含まれているものを可視化できます。
それほど巨大なアプリケーションでもないので、トータルで見ると微々たる効果ですが、ブラウザがJSを読んで動き出すまでが短くなるので、Time to Interactiveが15%ほど改善しました。SSRしているのでFirst Meaningful Paintなどは特に変化なし。
まとめ
ツール類は活かしきれなかったなーという気持ちがあるので、導入に加えて効果を出すまでを自由研究にしましょう、という反省。
