Mercari x Merpay Frontend Tech Talk vol.3
Creating Serverless CMS from Scratch
キャンペーンページのCMSを作った
以前のススメ方
フロントエンジニアがレビュー
PMに返す
QAが挙動確認
問題点
pugのラーニングコスト
レビュー時のスイッチングコスト
QAが各ステージング環境で確認
軽微な修正でも１から進めないといけない
キャンペーンページを打ち出すペースが月１くらいのスピード感
CMSを作る
何を作りたかったか
コンポーネントを組み合わせてページを作りたい
機能
２ページある
一覧
いままでの作成したもの
編集
pros
GUI上でコンポーネントを組み合わせて作れる
デザイナーのプログラミングを学ぶ必要がない
修正も容易に
cons
ない場合、コンポーネントを作り直さないといけない
OSSを使わなかった理由
自分たちの要件に合うものがなかった
どのようにつくるか
まずはMVPでやる
必要なコンポーネントは先に作る
ステージング環境はつくる
プロダクション環境にデプロイできる
元に戻せる
社内からしかアクセスできない
アーキテクチャ
Storage
JSON、Static files
保存時にはStorageに
publish時はステージングに置いて
ステージングをコピーして本番の環境に反映
今後はGAEでAuthenticationなどと連携できるようにする
フロント
将来
マシンラーニングでキャンペーンページに来たユーザーごとに適切なバナーを出したい
コンポーネントとは？
ひとまとまりの機能をもつ
自己完結型の
再利用可能な部品
Scoped CSS
本物のスコープをもつShadow DOMとは別
要素セレクタの指定は非推奨
属性と組み合わせると何倍も遅くなる
親スコープの影響がある
子のルーロ用差には子自身のデータ属性と親のデータ属性が付与
親はレイアウト目的で子のルート要素をスタイリングできる
意図せぬスタイルのバッティング
親と子で同じクラス名がなければ問題ない
deepセレクタで子コンポーネント以下に反映
ネストによって子のスタイルが負ける
回避方法
命名規則に則って固有のクラスを付与
BEM？
blockの粒度＝コンポーネントの粒度
elementは１階層のみ
modifireはアンダーバーで付与
組み合わせ次第で詳細度が高くなる場合もある
JSで扱うことが多いのでアンダーバーのが楽
メリット
書き方に統一性が生まれる
バッテイングしづらい
$options.name とSaSSのアンパサンドで省略可命名規則
Vue.jsのスタイルガイドか流用
２単語以上で構成
HTMLでは大文字も小文字扱いになるのでバッティングしやすい
密結合コンポーネント
ディレクトリ構成
コンポーネント分類
複雑すぎる分類はコスト大
階層が深いとpropsと$emit地獄になる
何のために分類するかを目的にする
粒度による分類
Part
Module
役割による分類
Presentational
COntainer
ステップ
1. 最初は分類しすぎない
2. 探しやすさのために粒度を小さくしていく
3. 役割の明確化のために分類
理想と現実
初期段階でユースケースに考慮したコンポーネントは困難
プロトタイピング的なプロジェクトは時間をかけても無駄になる
調整用は利用者としては便利
徐々に導入していく方法
1. すべては外部CSSに記述
コンポーネントの粒度の意識をしなくていい
2. 外部CSSとScoped CSSのハイブリット
共通は外部CSS
適用もとがわからない
それ以外はコンポーネントのScopedに記述
自由に書けてしまう問題
古いときに配置したときに表示が崩れる
3. すべてのスタイルをカプセル化
どこで使用しても同じ用に表示できることが保証できる
スタイルの影響範囲が明確
アップデートの周知がされないと同じものが作られる
テストの手間が増える
CSS設計はコンポーネント設計に活かせる
Webリアーキテクチャ
APIのためのクエリ言語と実装
サービスが返せるデータ構造をスキーマとして定義
周辺ツール・プラットフォーム
Client
Server
CLI
クラウドサービス・ゲートウェイ
なぜつかってるか
ドキュメントよりスキーマ
スキーマはドキュメントより実装と乖離するリスクが小さい
クエリの可読性が高い
クエリの数は特に制限をもうけてない
どうやってるか
Apollo Client
データの正規化機構をもってる
_typename と id をキーにしているキャッシュ機構を組み込める
Apollo Linkでリクエストの前処理・後処理ができる
ローカルステートも管理できる
Apollo自体はloaclとかremoteとかに関知していない
リモートのデータの取得と管理を任せたい
キャッシュによって遷移時のリクエストが減る
同じことをReduxでやると比べるとコード量が減る
任せていないもの
グローバルだけどローカルのデータ
Context 特定コンポーネントのみの局所的データ
State フォームはFormik
Apollo Server
型の名前を_typenameフィールドに埋め込める
拡張できる
HTTPリクエスト先のレベルに合わせたミドルウェア
コア機能のためのプラグイン機構
スキーマをフロントエンドのために整理
ロギング、認証の集約
将来的にgRPCを使ってマイクロサービスに接続していく
１つのエンドポイントだけ知っている状態
graphql-codegen で型を生成する生成した型を使ってリゾルバーを書く
処理を共通化したい
ロギング、認証、キャッシュ、CSRF対策など
ミドルウェアを書いた
ロギングは
formatError や formatResponse プラグインを使うそれ以外はディレクティブを使う
生成した型を使ってクエリを書く
ハマりどころ
formatGraphQLError お知らせややることは種類が多くて増える
型を
enum で定義していた列挙手は
string や number で置き換えたPractical tips for making a global EC site
UNIQLO Global ECについて
22カ国で展開している
O2Oもサポート
機能も異なる
メンバーシップ
チェックアウト
これまでのサイト
国ごとに異なる
メンテナンスの難しさ
クライアントヘビー実装
マイクロサービスとしゃべる
CDNが複雑
10万行近くのコード
フロントエンド原則
１つのコードで複数の国対応
パフォーマンス早く
アクセシビリティ事業
adminパネルなどのUXも上げてオペレーションコストを下げよう
タイムライン
カナダでローンチ
7カ国でローンチ
CDS2018にて紹介される
Google IO 2019にて紹介される
アーキテクチャ
SSRを部分的に適応
ナビゲーションのページに
リダイレクト・リライトルール
Proxy Cache
アグリゲーションはSSRとBFFで共有
BFFは20以上のサービスとREST API
グローバルサイトの取り組み
URL構造
ベース：
/:country/:language Accept-Languageヘッダまたはデフォルト言語を追加
Google Bot以外も考慮
HTMLを返したほうが無難
HTTP Status Codeを返せるように
翻訳バージョンを知らせる
hreflang="hoge" 各国のビジネスの人が管理
GAレベルを変更できる
スキーマを元にドキュメントを作成
CMSのレスポンスを各コンポーネントPropsにマッピングしてレンダリング
パフォーマンス
WebPageTestとlighthouseを国別でCSVで書き出し
ウィークリーで各国のレポートをメール配信
GTM経由のスクリプトがパフォーマンスに影響がないか？
最適化されているか？
SpeedIndex, TTIを指標にする
パフォーマンスバジェット
Total 200kb
Chunk 80kb
ローカライゼーション
言語別にエントリポイントを分ける
/ca/en
/ca/fr
ページに不要な翻訳がはいらないように
ランタイムでの翻訳
単数形、複数形の翻訳を容易
minification で削除されるので不要なロジックは含まないUSでの起訴は2000件以上
lighthouseチェック以外の確認
正しく画像の説明が挿入されているか
CSSなしでサイトが動くか？
https://validator.w3.org/ でHTMLがvalidか
DOMストラクチャが適切化
コントラストが適切化
キーボードだけで動くか？
webの画像利用について
画像は大きいほうがコンバージョンが上がる
5年前から10倍増えている
picture タグでのフォールバックAPIリクエストを束ねる
キャッシュ
セッション管理
２つのレイヤー
レスポンスキャシュ
コンポジットキャッシュ
HTTP Client
ロギング
セキュア情報はマスキング
Response timeをトラッキング
cURL formatでリクエストを買い出し
HMAC認証をサポート
大変なとこ
マイクロサービス間でAPIインターフェイスがアラインしていない
キャッシュのパージ
マイクロサービスのデザイン・実装待ちになりがち