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などは特に変化なし。
まとめ
ツール類は活かしきれなかったなーという気持ちがあるので、導入に加えて効果を出すまでを自由研究にしましょう、という反省。
Absintheをちょっと触った
Absinthe(アブサン、アブサント)というElixirのライブラリがありまして、GraphQLのAPIやってみよということでちょっと触りました。
ほんとにちょっと触っただけなので見せるコードもありませんが、いくつか思っていることを。
Schemaって分割できないんすか
ここでweb/schema.ex
というファイルにquery
を書いているのですが、ファイル分けたいなーなんて。Typeはimport_types
とか使えるんですが、import_query
は見当たらず。ソース読んだらわかるのだろうか。
queryのテストどう書いてく
Resolver
は普通に単体テストできるしmutationもなんとなく行けそうなんで置いといて、ConnCase
使ってquery投げてテストするとき、どうテストファイル分けようかな、というところ。いわゆるRESTなリソースベースならUserControler
とかあるわけですが、全部/graphql
にPOSTとかですし、リソースに縛られずに欲しいもの取れるとこが強みの1つなんで、リソースという考えは一旦ポイしようと。ところがどっこいじゃあどう分けましょうかね。queryに関しては思いっきり複雑なの数本投げておしまい、くらいでいいんすかね。
ファイル分けることしか考えてねーな。