INSIDE FRONTENDに行ってきました

最近のフロントエンド技術の動向を探るべく、INSIDE FRONTEND に行ってきました。

公式サイト/ TimeTable

初めての参加だったのですが、各公演後にAMA（Ask Me Anything）という投稿型の質疑応答が行われていて、手を挙げて質問できない人たちに向けた優しい取り組みだと感じました。（質問を sli.do に投稿して、いいねが多い質問からオーナーが順番に答えていく形式）

＊TypeScript: Why and how we adopted it at Slack

TypeScript の魅力についてのお話でした。基礎的な内容でデモもしてくだったので TypeScript を使ったことがない私にとって大変わかりやすかったです。
JSファイルの拡張子を変更しただけでTypeScriptとして動かすことができて型チェックをしてくれる、動作が軽い、VScodeのサポートが充実といった点が魅力で、特に大規模開発に向いています。
ただデメリットもあり、TypeScript で使う TSLint が ESLint よりも良くないということでした。
Slack は TypeScript に移行したことでバグが削減し、可読性が良い綺麗なコードにすることができたそうです。

＊Introduction to Lucet

Lucet についてのお話でした。
Lucet とはコンパイラ・実行環境のOSSのことで、Web Assembly を受け取って動きます。

WASI（WebAssembly System Interface）
WebAssembly（WASM）をWebブラウザ以外の環境で安全に実行するための仕様。
（参考：コンテナ技術を捨て、 WASIを試す）

私にとっては内容が難しく理解できないところが多々ありました。後々この分野について勉強して理解できるようにしておきたいです。

＊Nuxt.jsで中規模サービスを統合した話

ヤフーの電子書籍サービス「ebookjapan」で Nuxt.js を実際に使ってみて良かったこと、悪かったことの体験談のお話でした。
Node.js + Express , Nuxt.js を使っていて、Nuxt.js を選んだ理由としては、デザイナーが理解しやすい、ライブラリアップデートの手間が削減できる、SSRしたかったからといった理由からでした。（React については Redux と開発者が異なるといった点も懸念）

デザインは Atomic Design を採用し、UIの一貫性を保つ、変更に対応できるといった点に効果がありました。ただ Atomic Design のデメリットもあり、デザイナーからの成果物がHTMLでくるので Atom に分割する手間かかった、E2Eで成果を出すスクラムとの相性悪かった、といった問題も発生しました。デザイナーと一緒に導入したほうが良いそうです。

外部サービスのAPIを呼ぶ部分は mixins で行なっていました。mixins はVueファイルだけで使うのが良く、サーバーサイドと共通にするべきではないそうです。
パフォーマンス改善としては、処理フローを改善（描画後に取得してもいいものは後回し）、レスポンスサイズを削減、JSファイルの容量を削減（webpack-bundle-analyzerを使用）、不要なコンポーネント削除といったことを行いました。

APIドキュメントは Swagger、Blueprint を使用、Node.js のデプロイは screwdriver を使ってCIを回しています。

＊いちからデザインシステムを作ってみて学んだこと

（資料：https://efcl.info/2019/05/18/inside-frontend-2019/）
ヤフーの広告管理サービスでデザインを改善するチームが発足され、その活動についてのお話でした。
スタイルガイド作成、コンポーネントを細かく抽出して名前をつける、Sketchを使ってパーツを作成、デザインルールをドキュメント化といったことを行いました。
コンポーネントライブラリはHTML、CSS、JSをセットにし、CSS設計はBEM、スタイルガイドジェネレーターである Fractal を使用しています。

TypeScript 導入したことで型定義がデザインを厳格化できて良かったそうです。Storybookを使ってコンポーネント単位での見た目の実装をしました。
npmパッケージで提供するために、Storybookのコンポーネントをパッケージ化して React + GatsbyJS でスタイルガイドとして提供したいそうです。

＊BFFのDeveloper Experience

（資料：https://speakerdeck.com/quramy/bff-and-developer-experience）
Backend For Frontend のことで、マイクロサービスの統合をするために BFF で開発をしています。
Node(APIサーバー) + React(サーバーサイドレンダリング) を使っていて、バックエンドはドメインごとの開発に注力し、フロントエンドはUIに必要なAPIを開発すれば良いといったメリットがあります。
ただ、フロントエンドの仕事が増えてしまうので、バックエンドを待たないで開発を進めることにしたり、IDL（Swagger, gRPC, Thriftなど）でフロントとバックエンドのコードをそれぞれ自動生成するといった取り組みを行なっています。

テストで特定のAPIモックほしいとき、マイクロサービスだと処理に依頼をすればよく、アスペクト指向プログラミング（AOP）を使って共通処理を分離して横断的に使う手法を行なっています。

インターセプタを合成することでキャッシュなどを使ったテストも実行することができます。
Dev向けのUIを作ってテストしていて、特定のセッションのみ許可するようにしています。また、StorybookをUIで回してキャプチャするようにしています。
BFFに webpack を絡めるとDevサーバーを動かしにくいといったデメリットもあります。
StorybookとHMR（Hot Module Reloading）を使ってページ全体ではなくモジュール単位で更新するようにしています。CIが遅くなるのでリポジトリを分けています。

＊品質と開発速度を両立させるために捨てたものと守ったもの

（資料：https://docs.google.com/presentation/d/13QD86hxp0dB_xHkYcyLrFX1xNt0Vg4wsqIo8yeBQmFs/edit#slide=id.g5a1484322a_2_48）
競輪のサービスだったので、パフォーマンスとアクセスビリティを重視して開発を進めました。
HTTPフレームワークに Fastly を使ってレスポンスを向上させました。
品質については Performance budget を使って可視化して競合他社と比較、Speed Curveを使ってフロントのパフォーマンスをチェックし、設定した値を超過したらSlackで通知がとぶようにしています。また、Resource budget で設定した基準値を超過した場合は、プルリクエストを投げる時点でCIで落とすようにしています。
また、code-splitting と dynamic-import を使ってサイズの大きいファイルは読み込みを遅延させたり、Storybookを使ったビジュアルテストも行なっています。

全ページのキャッシュ、慣れたフレームワーク以外への挑戦、ある程度の負債については諦めましたが、レイヤードアーキテクチャにすることで負債を少なくすることができました。
FCP、TTI、SpeedIndex を使って競合他社と比較しています。
今後は Runtime Performance の最適化や WCAG Test、フォーカス・インジケーターのテストを実施したいそうです。

＊その他セッションの資料

＊所感

フロントエンドといっても担当する領域は各会社で異なるようで、フロントとサーバーサイドで担当が明確に分かれている会社もあれば、デザインからフロントまで担当するデザインエンジニアといったポジションがある会社もあり、サーバーサイドの開発経験が多い私にとっては BFF の働き方が理想に近かったです。
今回のイベントで TypeScript の魅力、マイクロサービスやDDD（レイヤードアーキテクチャ）を取り入れる会社が多いこと、Webパフォーマンスを意識した技術選定、計測ツールなどを新しく知ることができました。
TypeScript については流行っていることは知りつつも型をチェックすることでJavaScriptの良さである開発スピードが落ちるのではないかと懸念があったのですが、デモを見て簡単に導入することができることを知れたので今後使ってみたいと思います。
Webパフォーマンスの計測ツールや Storybook を使ったテストなど知らないことが多く出てきたので、必要な状況で使えるよう触ってみておこうと思います。

もぐもぐプログラミング