「Mercari x Merpay Frontend Tech Talk vol.4」に参加してきました

  • Mercari x Merpay Frontend Tech Talk vol.4に参加してきました。

mercari.connpass.com

タイトル 発表者
Pros and Cons of SSR and JAMStack @_sskyu
NoCode で CMS と連携するデザインツールを作っている話 @miyaoka
TypeScriptで型安全に入門したい @atsuco_02
Web Assembly と画像・動画 @Leonardo_engr

Pros and Cons of SSR and JAMStack

  • @_sskyuさん

SSRパフォーマンス

  • キャンペーンページのSSRのパフォーマンスがでない
    • NuxtでSSRしてる
  • Podをスケールして負荷に耐えていた(20Pod)
    • 単純なLPを配信したいだけなのに...
  • 負荷試験してみた
    • コンテンツの量でrpsに差が出た
    • SSRしない範囲を増やすと多少改善できた

nuxt generate(JAMStack)

  • nuxt generate
    • NuxtでhtmlをSSR時ではなくビルド時に生成する
  • 課題
    • nuxt generate時にuseragentがとれない
      • ios/android/web/appのwebviewで画面が違う
      • navigator.userAgentはSSR時はとれない
      • v-showでisAndroidとか使えばSSR時はotherになるけどクライアント側で正しい値取れて画面出せる

JAMStackに移行

  • キャッシュレスキャンペーンでJAMStackに移行
    • 2019/10/1-2020/6/30に出してるキャンペーン
  • 移行手順
    • JAMStack環境作る
      • 旧版と並行稼動
      • 社内のみからアクセス
    • 本番にデプロイ
      • テスト
    • 本番有効化
      • 切り替え
  • staticなファイルなので全てFastlyで配信
    • 以前はk8s上のNodeから配信
  • URL
    • 旧版と同じオリジンにおいた
    • 新版のURLにネームスペース付けた
      • そのままだとassets読み取れないけど相対パスで指定するようにして解決

Pros and Cons

  • SSR
    • サーバを運用してる
    • オンコール体制
    • スケールアウトでコスト増
  • JAMStack
    • 静的なassetを配信するだけなのでオンコール不要
      • ぺらいちなサイトに向いてる
    • 管理画面のようなサイトは不向き
  • パフォーマンスの比較記事

developers.google.com

NoCode で CMS と連携するデザインツールを作っている話

  • @miyaokaさん

Studio

  • GUIでWebページが作れるサービス
  • やってるユーザの操作に応じてstate更新して画面に反映してるだけ
    • 操作してる人からするとGUIだけで画面が作れちゃう
  • 課題
    • 静的なサイトはこれでできる
    • 動的なデータの概念がないので動的なサイトが作れない

動的ページを作る

CMSと連携

  • zero configで使えるようにしたい
    • 独自で作った
  • CMSで作ったコンテンツをデザインに注入できるように

TypeScriptで型安全に入門したい

  • @atsuco_02さん

型安全に入門したい

  • 型安全の良さを理解したい

環境構築めんどくさそう

  • CodeSandboxで環境構築いらず

TypeScriptって何者？

  • TSはJSにコンパイルされるスーパーセット
  • コンパイル前に型チェックが行われる
  • 値に対して型が決まると実行できる操作が明確になる=型安全
    • 型があると操作が限定される=>意図せぬエラーが防げる

JSとTSの方の違い

  • JSにも型ってあるよね
  • JS
    • 実行時に型を判別
    • 自動で型変換される
  • TS
    • 実行前に型を判別

TSの型の良さ

  • 型を明示的なので可能な操作が明確
  • 暗黙的な変換がされない
  • コンパイル時にある程度エラーがわかる

Web Assemblyと画像・動画

  • @Leonardo_engrさん

JavaScriptだけで画像加工

github.com

  • PWAのアプリが増えてきている
    • 画像加工のような処理もクライアント側でやりたい
  • ImageMagickにできることならだいたいできる
  • 画像を比較してdiff出せたりする

JavaScriptだけで動画をエンコード

  • ffmpeg.js
    • あまりメンテされてない

github.com

  • スマホの処理性能上がってきてる
    • リアルタイムで画像にエフェクトとかアプリだとでてきてる
  • WebWorkerと組み合わせて使えるように用意してくれてる

「#webbundle_study」に参加してきました

  • webbundle_studyに参加してきました。

web-study.connpass.com

タイトル 発表者
Web Packaging: Web Bundles @horo
WebPackaging Spec @jxck

Web Packaging: Web Bundles

  • @horoさん

Web Packaging

  • Webリソースをひとまとめにする技術
  • W3Cで検討されている仕様
  • その中にWeb Bundles

Web Bundles

  • HTTPリソースをまとめるための仕様
  • .wbn
  • 近くにいる人にwbnをシェアすることもできる
    • アプリで
    • USBで
  • ファイルがローカルにあるので表示がはやい

Web Bundleの作り方

www.npmjs.com

Subresources Web Bundles

  • linkタグでwbnからとってくると指定できるようになる
  • htmlごとbundleするのではなくcssとかjsだけbundleするようなシーン

Page Web Bundle

  • 同一originでなくても同一originのようにロードできる
  • アセットがたくさんあるような場面で使うイメージ

Save as Web bundle

  • ページを右クリックからwbnで保存できるようにする
  • 印刷して保存するような雰囲気
    • cacheにアクセスしたりとかはできない

TWA

  • PWAをPlayストアにAndroidアプリとしてあげられる
  • 動きとしては特定のURLを開く
  • 課題として初回アクセス時オフラインだと表示できない
    • Web Bundleでかいけつできるのではないか

WebPackaging Spec

WebPackaging Spec

  • SXG
  • Web Bundles
  • Loading

Web Bundles Spec

  • どういう風にbundleが動くかしか定義してない
  • arrayをcborというフォーマットでバンドルする
  • index/response/signetureなどどこに入ってるか決まってるから全部パースしなくても欲しい情報をとれる
    • zipとかだとそういうことできないからわざわざwbnを使ってる
  • どのaccept-type来たらどのcontent-type返すかとかハンドリングできる
    • 多言語用意しておいてaccept-languageによってどれ返すか制御したりとかが想定ユースケース
    • 配布することも考えると多言語全て入れておいた方がいいかもとかっていう話も
  • bundleしてる各ファイルに対して署名しないといけない

Serve Web Bundle

  • HTTP
Content-Type: application/webbundle
X-Content-Type-Options: nosniff

「年の瀬に振り返る Figma & React コンポーネントでのサービス開発」に参加してきました

spacemarket.connpass.com

タイトル 発表者
Figma・Storybookでのコンポーネント運用から考えるデザインシステムとの付き合い方 伊東 将太
2019年の Atomic Design コンポーネント設計 原口 渉
パネルディスカッション 横井 麻里乃 / 小林 春彦

Figma・Storybookでのコンポーネント運用から考えるデザインシステムとの付き合い方

  • 伊東 将太さん

FigmaでUIコンポーネントを運用

  • どんなコンポーネントがあるか視認性を高めたい
  • 操作感を確かめられるようにしたい
  • AtomicDesign
    • Atomsはデザイナー
    • それ以降は実装しながら
  • デザイナーとフロントエンドエンジニアの協業が楽になった

運用していく中で

デザインシステム

  • デザイン原則
  • ガイドライン
  • カラーパレット
  • アイコン
  • パターンライブラリ

Storybook

  • コードでデザインシステムを可視化できるのがいい
    • より本番に近い状態

まとめ

  • プロダクトの方向性を明確にして開発効率/一貫性を向上したければ取り入れる価値ありそう

2019年の Atomic Design コンポーネント設計

  • 原口 渉さん

マークアップ

コンポーネント推進PJ

共通コンポーネントの反映

  • せっかく用意してあるのに使われていないページがあった
    • 同じコンポーネントｗｐそれぞれで実装しているため修正もれやデザインのばらつきが起きる
  • 共通ライブラリを変更したら利用者も更新されるようにした

コンポーネントの粒度と命名規則の策定

  • 明確に決めてなかったので作業者によってばらついていた
  • 似た見た目でもコンポーネントを分ける
    • 再利用性は副次的なものと考えた
  • OrganismsとMoleculesの基準
    • 単体で意味を成せばOrganisms
  • 命名規則
    • Page名を接頭辞につける

課題管理フローの策定

  • JIRAで可視化

プロダクトとStorybookの状態が異なる

  • 本番だけ反映されてStorybookが更新されていないことがあった
    • storiesのファイルを先に書くようにした？
    • 定期的にチェックするようにした

まとめ

  • デザイナーとエンジニアで共通の認識を持つことができた
  • デザイナーと連携とりやすくなった

パネルディスカッション

  • 横井 麻里乃さん
  • 小林 春彦さん

なぜAtomicDesign

  • photoshopのファイル数が150超
    • 管理しきれなくなった
  • もともとデザイナーとエンジニアで別リポジトリで同じようなもの管理してた

組織的なコンポーネント運用の課題

  • リリース優先でコンポーネントをきれいに運用することは後回しになりがち
    • Atomsだけはきれいに管理すると決めている
  • 同じ設計ルールで誰でも作れるようにする工夫が必要
    • 自動化とか仕組み化をしていきたい

なぜFigma

  • いろいろ変遷してる
    • コミュニケーションがしやすいからFigmaにした
    • Figmaにコメント書くとSlack連携できるように

「【We Are JavaScripters! 3周年記念】 WeJS Festival !」に参加してきました

  • 【We Are JavaScripters! 3周年記念】 WeJS Festival !に参加してきました。

wajs.connpass.com

  • WeJSの3周年記念のイベントに参加してきました
  • 自分が初めてWeJSに参加したのも2017年7月に開催された9thなのでもう2年以上前です。勉強会に行き始めたころなので懐かしいものです。
発表枠 タイトル 発表者
初心者LT はじめてのユニバーサルJavaScript @りゅーそう
初心者LT A story about making a cli twitter client with typescript @azawakh
初心者LT styled-components の ` ←について @kimizuy
初心者LT 逆算して考える広告ライブラリ @ta__ho
初心者LT Node.js/serverlessでおこなうDX改善 @Ayami Otani
通常LT おさらいVue Composition API Morita_Masatoshi
通常LT Lighthouse CI入門 @yinm
通常LT Reactの歴史 @mqtsuo02
通常LT 執筆の進捗を支える技術〜Could RunでBot作ったらとても便利だった件〜 @kyasbal
通常LT angular歴3ヶ月がAngularと本気で向き合ってみた @EmiYaegashi
Demo LT PlayCanvasでできたこととデモ @sushucorn
Demo LT TensorFlow.jsとobnizで作る笑顔あふれる職場 @boiyama
Demo LT Ma_gician ＜Vue にはできないこと(2)＞ @StewEucen
Demo LT 今日から始めるWeb USB @takanorip
Demo LT Joy-ConをJavaScriptでプレゼンリモコンにした話 @mascii_k
Short Session Introduction to ReasonML @Naturalclar
Short Session JSXでつくる宣言的プレゼンテーション @mottox2
Short Session JSでの時間の使い方の話 @chikoski
Long Session Behind the scene @brn227
Long Session Babel plugin を作って AST と Babel を学ぶ(ライブコーディング) @mki_skt

Introduction to ReasonML

  • @Naturalclarさん

Reason

  • State of JS 2018
    • 半分は聞いたこと無い
    • 使ってる人の満足度は高い
  • Reactの作者Jordan Walkeが作っている
  • Ocamkを別のSyntaxで書いたもの
  • 強力な型
  • BuckleScript
    • JSにトランスパイルする
  • 特徴
    • JSのように書ける
    • React書ける人は馴染みやすい
  • 利点
    • ビルドが高速
      • 規模が大きくなっても数秒
    • バンドルサイズが小さい
      • 結果が自明なものはトランスパイル時に変換してくれる
    • Prettier完備
      • もともとはReasonのフォーマッターが優秀でそれをJSでも使えるように作ったのがPrettier
    • 型安全性
    • エラーメッセージがわかりやすい
  • gentype
    • tsxを生成したりできるライブラリ
    • 徐々に移行したいときはこれを使うといい
  • reason-react-native
  • reason-native

JSXでつくる宣言的プレゼンテーション

  • @mottox2さん

KOBIT

  • GoogleAnaryticsと連携するとPowerPointのレポートができるサービス
  • PowerPointはzipされたxmlの集合体
  • レポートなのでmarkdown to pptxでは表現できない

課題

  • コードから生成後の見た目が想像しづらい
    • JSXで宣言的に書く
  • 座標計算が大変
  • JSXからSketchを生成するReact Sketch.appを参考に

仕組み

  • react-test-renderer
    • JSXをObject化できる

github.com

JSでの時間の使い方の話

  • @chikoskiさん

JavaScriptの実行タイミング

  • どんな順番で呼ばれるの？
    • addEventListener
    • requestAnimationFrame
    • requestIdleCallback

EventQueue

  • タスクはキューにたまっていく
  • キューの中の処理でスタックがたまっていく
  • いろんな処理が全て同じキューに溜まっていく(メインスレッド)
  • Chromeのdevtoolsのperformanceでタスクキューを見れる

実行の順序

  • Dont yield
    • 普通のJSの処理
  • Microtask
    • awaitとか
  • requestAnimationFrame
  • Inter-frame
  • requestIdleCallback
    • CPUが暇な時に動く

Worker

  • 全部メインスレッドでやるのをやめようという話もある
  • UIスレッドをわける
  • Worker
    • EventQueueをもう1つ作る
    • 並列に実行される
    • コンストラクタの第2引数に{type: module}でESModulesも使えるようになる
    • postMessageはJSオブジェクトなら渡せる
      • コピーして渡される
        • 処理時間は無視できる程度
  • Comlink
    • postMessageを抽象化してくれる
  • SchedulingAPI
  • 無限ループを書きたい時
    • priorityを設定できるようになる仕組みも考えられている
    • それを使えばブロックしないようにできる

Behind the scene

  • @brn227さん

Scriptのクリティカルパス

  • HTMLをparse
  • リソースをfetch
  • V8が実行

Resource Fetch

Scriptタグの種類

  • ClassicScript
    • 普通のscriptタグ
  • ModuleScript
    • ESModleに対応したscriptタグ
    • import/exportを解決できる
  • Async
    • scriptタグの順番待ちが発生しないロードも実行も非同期
  • Defer
    • ロードは非同期だけど実行は順番を待つ

Connection

  • HTTP1.1だと同時接続数の上限がある
    • 大抵のブラウザは6まで
    • なので非同期で同時にたくさん取りに行っても上限を超えると待たされる
  • HTTP2だと1つのコネクションで複数のやりとりできるので解決される

Fetching

  • ブラウザキャッシュがあるかチェック
    • ETag
      • リソースに対して一意に発行されるハッシュ
      • Cache-ControlとETagを組み合わせてキャッシュを使うか決める
    • ServiceWorker
      • リクエストをインタラプトできる
      • ChacheStorageに入れておいてそれを返すことができる

最適化

  • Preload
    • link rel=preload
      • 事前にリソースをリロードさせておける
  • Compress response
    • gzipではなくBrotliを使うと更に圧縮率高められる
  • CDN
    • 地理的に近いところから取得
  • webpackプラグイン
    • Workbox
    • sw-precache
  • Code Splitting
    • 必要なものだけを取得できるように

Futuer

  • HTTP/3 Quic
    • Transport層を置き換える
  • Priority-hints
    • linkやscriptにimportance属性が追加される
    • highがついてれば優先的に取得する等
  • WebBundle/WebPackaging
    • Webのコンテンツを1つにパッケージングして配信
      • 画像でも動画でも全部
      • request/responseとか証明書とかも
      • Webサイトまるごとpackagingして配信して使える

Parsing

  • fetchしたscriptをASTに変換するフェーズ
  • parse処理は重い
    • ページする度に全部parseしてるとおもすぎる
    • 最初は関数と行数だけparseしておく
    • 呼び出されると関数の中身までparse
  • parseも全部メインスレッドで動いている
    • parseが始まった段階でHTMLの表示がとまる
    • deferとかasyncをつけると変わる

Streaming

  • Streamingで逐次取得しながらparseする

bundle size

  • 50-100KB目安に分割するとよい
    • モバイルとかも考えると
    • CPU/メモリ使用量がかかる

Transpile

  • 古いブラウザようのコードは新しいブラウザにとっては無駄なコード
  • ブラウザに応じて調整すると無駄なものを減らせる

JSON.parse

  • objectにこれをつけておくと遅延してparseされるのではやくなる

Polyfill

  • CoreJS全部入れちゃったりすると無駄が多すぎる
  • polyfill.ioを使って必要なものだけにするといい

Futuer

  • Binary AST
  • ASTで直接配信する
    • ブラウザごとに共通仕様ができればいける

Babel plugin を作って AST と Babel を学ぶ(ライブコーディング)

  • @mki_sktさん

AST

  • Abstract Syntax Tree
  • プログラムの構造を示したデータ
  • JSではJSON
  • 仕様はESTreeに準拠
  • AST Explorerを使うとJSのコードがどう変換されるか見られる

astexplorer.net

Babel

  • JSのコンパイラー
  • もともとは6to5だった
    • ES6 to ES5
  • そこからいろんな機能が追加されていった
  • 新しい構文で書いたJSを古いブラウザでも動かしたい時に使う

構文変換

  • TS/JSX/JSなど -> Babel -> JS
  • 変換のフェーズ
    • Parsing
    • Transformation
    • Code Generate
Parsing
  • @babel/parser
  • コードをparse関数に通すとJSONで出力される
  • acorn
    • 軽量なJS parser
    • webpackで使われてる
Code Generate
  • @babel/generate
  • ASTをJSに変換する
Transformation
  • @babel/traverse
  • constとletをvarに変えるといった変換を行う

ライブコーディング

github.com

「JSConf JP(Day2)」に参加してきました

  • JSConf JPに参加してきました。
  • 2日目の参加メモです

jsconf.jp

タイムテーブル

時間 タイトル 発表者
11:00- 時間はただの幻想である… JavaScriptにおいては Jennifer Wong
InversifyJSを用いたレイヤードアーキテクチャの構築 奥野 賢太郎
Vue.js で D3.js を使ったインタラクティブなデータの可視化 Shirley Wu
11:30- ストリームの人生 Dominic Tarr
Build and scale multiple Voice application by using TypeScript Hidetaka Okamoto
13:00- Web の体積 Jxck
正攻法はあるのか !? 泥臭く戦った Node.js バージョンアップ一部始終 Masato Nishihara
パスワードは90年代の代物だ Sam Bellen
13:30- JavaScript, Rust and Wasm Walk into a Ramen Shop ... Irina Shestak
Migration from React Native to PWA ohbarye
npm i -g @next-and-beyond: Building the future of package management Claudia Hernández
14:15- JSConf Panel Talks Jan Lehnardt and Yosuke Furukawa
GraphQLを用いたECサイトにおけるパフォーマンス改善 澤井宣彦
Minimum Hands-on Node.js 栗山 太希
14:45- 悪用された npm パッケージの分析 Jarrod Overson
JavaScriptのままでTypeScriptを始める 高梨ギンペイ
15:30- Browser APIs: 知られざるヒーロー達 Rowdy Rabouw
Your benchmark may not guide a real application performance Tetsuharu OHZEKI
16:00- Anatomy of a Click Benjamin Gruenbaum
JavaScriptとSwift/JavaをつなげるCapacitorと、これからのWeb Frontned. 榊原昌彦
Recruit Speed Hackathon 新井 智士
16:45- AIとJavaScript による生物認識 Jonny Kalambay
大規模アプリケーション開発でのElm実践 海老原 圭吾
17:15- Pika: レジストリの再創造 Fred K. Schott
最新のWeb技術でIoT開発をする 木戸 康平

InversifyJSを用いたレイヤードアーキテクチャの構築

  • 奥野 賢太郎さん

密結合とは

  • 修正を加えた時にその影響箇所が見つけづらい状態
    • 予期しないところに影響が及ぶかもしれない状態
    • DBの構造
    • 外部サービス
    • APIの構造
    • 画面の構造
  • 例
    • 画面の入力フォームの構造のままテーブル設計してしまった
    • 画面の構成変えたけどDBいじる余裕ないから無理やり対応することに・・・
  • 抽象化する中間の層が必要

レイヤードアーキテクチャ

  • DDD
    • Domain Driven Design
  • MDD
    • Model Driven Development
  • Repository

DIP

  • InversifyJS
    • DIの機能を提供するライブラリ
    • constructor injectionできる
    • TypeScriptで書いた方が相性が良い
  • TSyringe
    • Microsoft製
    • InversifyJSと同じ感じのやつ
    • 好みではあるけど登壇者はこっちの方が好き
  • レイヤーごとにmodel objectを用意する
    • バグが起きたときの影響範囲がわかりやすいように寿命を短くするとよい
  • value objectを作るようにする
    • バリデーションはconstructorで
  • knex
    • ORMapper

Build and scale multiple Voice application by using TypeScript

  • Hidetaka Okamotoさん

スマートスピーカーのバックエンド

  • 音声/言語処理系の知識がなくても開発できる
    • Speach To Textや自然言語処理はサービス側の責務
    • バックエンドには処理後のJSONが送られる
  • Webhookの開発と同じような感じ
    • SlackやLINEのbotに近い
  • 文脈を覚えておくためにDBも持っておくことが多い

Alexa開発

  • ask-adkを使う
  • スキルが増えると起こる課題
    • スキルが増えるとLambdaも増えるからruntimeの更新など面倒
    • 同じような処理がいろんなスキルに存在してしまう
  • 多機能な1スキルか単機能な複数スキルか
    • 単機能なスキルの方が使いやすい
    • でも見つけてもらうのが大変かも
  • ServerlessFrameworkを使うと便利
    • 全部yamlで管理できる
    • runtimeのアップデートなども設定かえるだけ

まとめ

  • VUIはWebhookライク
  • in/outのフォーマットが一定のためTS相性良し
  • 汎用FWがまだない

正攻法はあるのか !? 泥臭く戦った Node.js バージョンアップ一部始終

  • Masato Nishiharaさん

背景

  • Node6を使ってたが2019/4にEOL
  • Node8は2019/10にEOLだったので一気に10に
    • 10のEOLは2021/4

やったこと

  • Node変更差分確認
  • 依存パッケージの変更差分確認
  • 全機能テストを複数回

パッケージの差分

  • 依存ライブラリのリリースノート全部見たりするのは現実的でない
  • Node10に対応しているか明記していないものもあった
  • =>全機能テストで動けばよいとすることに

全機能テスト

  • ブラウザバリエーションもあるので大変
  • 1回目で不具合を出して対応して2,3回目もやった

リリース後

  • CPU100%にはりつくトラブル
  • スレッドの切り替えをする処理が多発していた
    • Nodeはシングルスレッドじゃないのか？
    • 内部的にはマルチスレッドで動くところもある
    • libvuの中でマルチスレッドを利用している
  • このケースでは原因はDBサーバだった
    • 障害のあったサーバからDBサーバへのアクセスが遅延していた

まとめ

  • こまめに上げるようにするとよさそう
  • コアな部分だけでも自動テストはあった方がいい

Migration from React Native to PWA

  • ohbaryeさん

React NativeからPWAへ

  • iOS/Andorid対応のRNアプリをiOS/Android/Web対応のPWAにする
    • 後者のiOS/AndroidはWebViewでPWAを表示する

なぜReactNativeだったか

  • プッシュ通知など使いたいからスマホアプリがいい
  • iOSエンジニアがいなかった

BYOD化

  • 端末を用意してインストールして渡してた
    • 端末配布をやめてBYOD化することにした
    • Android版の提供も始めることにした

マルチプラットフォーム対応

  • iOSで動くのにAndroidで動かないとかがかなりあった
  • JSのエラーなのかライブラリの中身が悪いのかネイティブのレイヤーが悪いのか

パッケージ管理

  • ReactNativeはnpmでライブラリ管理してるがその先にiOS/Androidのライブラリがある

ビルドデプロイシステム

脱ReactNativeの選択肢

  • PWA
  • Nativeで書き直す？
  • Flutter
  • => ブラウザで見たいという要件もあったのでPWAで
    • React使った

通知

  • Push Notificationの実現
    • AndroidはWebでも使える
    • iOSはWebViewとして使うのでネイティブの機能を使う

WebViewで苦労したこと

  • キャッシュのレイヤーが増えることに注意
  • WebViewのキャッシュを無効化するメソッド用意したりとか

PWAで供料したこと

  • Android ChromeだとアイコンにつけるバッヂはまだExperimental
  • フォアグラウンドでの通知がAndroid PWAだけ挙動が違った

テスト

  • cypressでintegrationテスト書いてる
  • ReactNative時代はスナップショットテストとかやってた

運用してみて

  • Webなので即時反映されるのでいい

まとめ

  • チームメンバーのスキルセットにあった技術選定が大事
    • 開発できる = 運用できるではない
  • モバイルアプリに近い体験要求されてもWebでもできるかも

GraphQLを用いたサイトにおけるパフォーマンス改善(ECサイトを題材に)

  • 澤井宣彦さん

背景

  • 歴史が長くページ遷移が遅い
  • 全社のリブランディング
  • ページ遷移の改善
  • 技術スタックの改善

リニューアル

  • フロントはReactをTSで
  • Backendは既存RailsをAPI化
  • API定義はGraphQL
    • トップページをリッチにしたい構想
    • フロント側に自由度をもたせたいから

パフォーマンス改善

計測

  • 実機で行うテスト
  • 合成環境で行うテスト
    • PageSpeed Insighrsを使った

ボトルネックの特定

  • ChromeのAudit
  • Opportunitiesの改善項目

改善

フロント側の改善
サーバ側の改善
  • APMを活用
    • 既に入れていたDataDogを活用
  • N+1のDBアクセス問題
    • batch-loader(rubyの場合)などを使って対応するようにする
QueryとSchemaの改善
  • ページングのない配列のrequest
    • 関連するレコードが全件取得されるので性能が劣化
    • ページングをつけて件数指定する
    • schemaのlinterで未然に防げそう
  • 全く使ってないデータを取得している
    • queryを消せばよい
    • なぜ画面に紐付いてないqueryが書かれてしまうか
    • FragmentとColocation
    • Fragment
      • queryを部分的に切り出したもの
      • 再利用できる
      • 部分定義できる
    • Colocation
      • Fragmentを集約して1つのqueryにまとめる
    • Reactコンポーネントの階層とqueryの階層をあわせるようにする

今後

  • Cacheの活用を検討
    • リアルタイム性が低いコンテンツもある
    • ゲストユーザは同じものが基本的に表示される
    • CDNのレイヤーでHTML/responseどちらもできるはず

JavaScriptのままでTypeScriptを始める

  • 高梨ギンペイさん

TypeScriptのいいところ

  • JSのスーパーセットであること
  • 型を持つこと

Typed-JavaScript

型がつくと何ができるようになるか

  • バリデーションできる
    • 関数を呼ぶ時にどんな引数を渡さないといけないか？
      • ドキュメント見る？
      • 動かしてみる？
      • 型があればすぐに分かる
      • エディタが対応してればその場でわかる
  • エディタの補完がきく
    • 自分で作ったAPIの補完も型を用意しておけば補完される
    • 標準関数なんかもググらなくてもその場で候補がでる
  • リファクタリングがしやすい
    • 変数名後から変えたり型を後から変えたり
    • 変更漏れがあればコンパイルエラーになってくれる

使い方

  • tsconfig.json
    • allowJsをtrueで.js対象になる
    • checkJSをtrueでjsもチェック対象になる
    • noEmitをtrueで型チェックだけするようになる
    • checkJSをfalseにしてチェックしたいファイルにコメントで@ts-checkつけるでもいける

まとめ

Your benchmark may not guide a real application performance

  • Tetsuharu OHZEKIさん

ソフトウェアのパフォーマンス

  • 遅いソフトウェアより速いソフトウェアの方がよい
  • どのように速くするか
    • Dont't guess, measure
  • ベンチマークを使う

ベンチマーク

  • シナリオに沿ったベンチマークになってますか？
  • 一般的な指標はベンチマークの1つでしかない
    • Lighthouseだけやってればいいわけではないケースも多い

JSの最適化

  • 一度の実行だと数ミリsecで差がわかりづらい
    • じゃあ数万回実行しよう
    • =>それでいいの？
      • 何度も実行されるとJSVMが複数レベルで最適化してくれる
      • その処理は何度も呼ばれるような処理なのか？

どのように改善を進めるか

  • プログラムを速くするには遅くなるようなことをやらないことが重要
  • CIとしてベンチマークを計測して継続してプロットするといい
    • 容易に起動できて再現可能であるようにする
    • 細かい上下は必ず起きる
    • 長期での傾向をチェックする

まとめ

  • パフォーマンスを改善するにはリアルなシナリオが必要
  • 闇雲に測定するのではなくリアルなシナリオに基づくこと
  • ベンチマークテストをテストケースの1つとして追加し実行できるようにすること
  • まずはどのように使われていてどのように速くなると嬉しいのか調べるところから

JavaScriptとSwift/JavaをつなげるCapacitorと、これからのWeb Frontned.

  • 榊原昌彦さん

Capacitor

  • Webでアプリを作ってWebViewで表示できる
  • ネイティブの機能にアクセスできる
  • デスクトップアプリとしても作れる

Capacitorの使い勝ったあ

  • @capacitor/core
  • @capacitor/cli

iOS

  • SwiftをどうやってHTML/JSにつなげるのか
    • npx cap init
    • WebViewを100%表示されるものができる
    • Poddileでnode_modulesの中から引っ張ってきてる
  • HTML/JSがどうやってSwiftにアクセスしているか
    • ブリッジがwindowオブジェクトに値を埋め込んでる
  • Androidもだいたい同じ

UI

  • iOS/Androidそれぞれガイドに沿った見た目にできる