🍃このブログは移転しました。
3秒後、自動的に移動します・・・。

Mercari x Merpay Frontend Tech Talk vol.3 に行ってきたメモ

Web

Mercari x Merpay Frontend Tech Talk vol.3 - connpass

六本木のメルカリ社にて。

Creating Serverless CMS from Scratch by @sottar_

create own CMS from scratch - Speaker Deck

  • 海外のカンファレンスで発表したやつの再演だそうな
  • CMSをつくったはなし
    • 期限つきキャンペーンページを作ることがおおい

今までの業務フロー

  • デザインをPMが考える
  • デザイナーがHTML/CSSなど
  • JSが必要ならフロントエンドエンジニアに頼んだりも
    • レビューもする
  • 問題だったところ
    • デザイナーがコードを書く必要がある（HTMLはまだしもpugとか
    • エンジニアのレビューのコスト
    • ちょっとした修正でも同じフローをたどるので時間がかかる
  • キャンペーンページの複雑さに比べて、コスパが悪い
  • なのでCMSをつくった

なぜ自作したか

  • 共通のコンポーネントで対応できるデザインだった
  • 既存のCMSもためした
  • 必要な機能はたくさんあったが、まずMVPを作ってアップデートしていくことに
  • 以下の機能だけつくった
    • リストページと編集ページ
    • 既存ページをカバーした数のコンポーネント
    • stage/prodへのリリース機能
    • unpublishする機能
    • 社内NWからのみアクセス

アーキテクチャ

  • AWSとGCS
  • ホスティングはS3
  • データはGCSで、CloudFunctionで取得
  • フロントはReact
  • publishするとそれがS3に
  • Q. GCSとAWSを使ってるのはなぜ？
    • A. 既に社内からのみアクセスできるS3の仕組みがあったので
  • Q. CloudFunctionいる？
    • A. 直接GCSを叩いてもいいけど、後で機能追加しやすいと思ったから

使ってもらったあと

  • おおむね好評
    • 業務フローも改善された
  • 機能追加していこうと思ってる
    • 権限管理
    • SSR
  • もっと先には
    • 機械学習などを使って、ユーザーごとに最適化したバナーや表示をしたい

必要なものを自分たちで作れるのってやっぱいいよね〜。

Vue.jsでのCSS設計 by @tacamy

CSS Architecture on Vue.js - Speaker Deck

  • HTML/CSS歴10年！
  • Vue.jsはここ2年くらい
  • `.vue`でのScopedCSSにおけるベストプラクティスを話します

コンポーネントとは

  • 自己完結する
  • 再利用可能
  • VueのSFC(SingleFileComponent)

念願のScoped！ただし

  • ShadowDOMではない
    • data属性でなされてる
  • 要素セレクタへのスタイル指定はダメ
    • 遅い
    • クラス名を使おう
  • ルート要素は親スコープの影響を受けるので非推奨
    • 親から子のレイアウトをいじれるメリットもある
    • クラス名が被らなければよい
  • deepも避けたい
    • ネストによって優先度が変わるかもしれない
    • Scopedでもない

BEMにならう

  • block = コンポーネントと捉える
    • 他はBEMと同じ
  • CSSは1階層にとどめる
  • modifier
    • BEM式にすると冗長すぎる
    • `_modifier`の形式でつければ、詳細度も上がって便利
    • アンダーバーならJSから触りやすくてよいと思った
  • BEMという共通認識
    • DevToolsで見てもすぐわかる
  • BEMだとタイピングめんどうでは？
    • クラス名を変数に入れてアクセスする
    • SCSSにして`&`を使う

BEMのガイドライン

  • 名前付けは2語がおすすめ
    • HTMLの要素は1語なので
  • ファイル名とディレクトリ構想

コンポーネントの分類について思う

  • AtomicDesignは複雑すぎる説
    • あれはどれでしたっけ問題
    • 細かすぎる
  • 粒度によって分ける案
    • Part / Module
  • 役割別にする案
    • Container / Presentation
  • プロジェクトに応じて最適な粒度を見つけるべき
    • 分類に時間がかかる = too much

理想と現実

  • すべてのCSSをScopedにできれば
    • 構造も一貫しており保守もしやすい
  • 初期にすべてのユースケースを見通すことはできない
  • スピード重視だと、雑に書き捨てたいシーンも多い

どうやっていくか

  • Step1: まずは外部CSSからはじめる
    • o: HTMLにクラスつけるだけでOK
    • x: ただしどこで使われてるかわからない
    • x: エンジニアがCSSを状態によって付け替えたりしてると、それを把握しないといけない
  • Step2: 外部CSS + Scopedのハイブリッド
    • o: Scopedなので自由にCSSかける
    • x: 同じようなものが点在する
    • x: 一部だけ外部CSSに依存したコンポーネントがいたりする
  • Step3: ぜんぶScoped！
    • o: どこでも同じデザインが使える
    • x: コンポーネントのメンテを続けていく必要がある

まとめ

  • 正解はないです
  • プロジェクトに応じたものを
  • CSS設計のノウハウは、コンポーネント設計にも活かせる！

質問

  • Q. Scopedのみからはじめなかったのは？
    • エンジニアのみの環境だと、Scopedのみからはじめたほうが嬉しそう
  • A. ユースケースを想定したコンポーネントを初期に用意するのが難しい

The Challenge of Web re-architecture using GraphQL and Apollo by @lightnet328

The challenge of Web re-architecture using GraphQL and Apollo - Speaker Deck

  • 新卒では働いてます
  • メルカリWebのリアーキテクトをしてる

リアーキテクト

  • 新しい技術スタックで作り直す
    • 機能はそのまま
  • ページごとに開放していってる
    • いまはトップページだけ

GraphQL

  • APIのためのクエリ言語
  • クエリでデータを引いてくる
    • 型がつく
    • gRPCのprotobufみたいな
  • クエリとレスポンスのデータ構造が一致する
  • 周辺ツールも充実してる
  • スキーマ定義
    • 実装がそのままドキュメントになるイメージ
    • 可読性も高い

Apollo Client

  • GraphQLクライアントの1つ
  • データを正規化する仕組みがある
  • キャッシュ機構もある
  • リクエストの前後に処理をはさむLinkという機能がある
  • Apollo Clientで取得しないもの
    • グローバルで使うけど、ローカルでしか使わないデータ（Contextで）
    • 局所的なデータ（State）

Apollo Server

  • GraphQLサーバーの1つ
  • 拡張できる
  • BFFとしての役割
    • うしろにバックエンドサーバーが控えてる
    • フロントエンドのためにAPIを整理
    • ロギング、認証もできる

開発フロー

  • APIクライアントをかく
    • ここがいちばん大変
    • ドキュメントとの齟齬があったりする
  • スキーマ定義して型にする
    • フロントエンドで使いやすい形に
    • graphql-codegen
  • リゾルバーを書く
  • クエリを書く

ハマるところ

  • リゾルバーの共通処理をまとめたい
  • enumが増えすぎると対応が漏れてフォーマットエラーに
    • 単にstring/numberにした

まとめ

  • エコシステムが出来上がってきている
  • Apolloだけでなく、他のツールも使って補っていく
  • 型安全に開発スピードをあげられてよい

質問

  • Q. クエリが増えてきたときに、数や深さの制限はしてる？
    • A. 数はしてたと思う

Practical tips for making a global EC site by @yayoc

資料はみつけたら

ユニクロのEC

  • 22ヶ国
  • O2Oもサポート
    • 店でバーコード出すとか
  • 国によって機能が異なる
    • 開発も国ごとになるのでメンテがつらい
  • クライアントに実装が偏る
  • CDNの設定もすごい
    • 10万行の設定ファイル

それを改善する

  • やりたかったこと
  • 2017~2019年でやってた

アーキテクチャ

  • 国別リダイレクトはNginxで
  • URL
    • `/:country/:language`
    • 位置情報
    • Accept-Languageヘッダと、デフォルト言語で
  • 部分SSRな理由
  • CMSで管理されてる
    • 柔軟性は高い
    • CMS側で定義したスキーマをいじるだけ
    • それがReactのpropsになって表示される
  • パフォーマンスへの取り組み
    • デイリーで国別にWPT/LighthouseしてCSVに
    • 結果をウィークリーでメールして意識させる
    • webpack-bundle-analyserもよく見てる
  • i18n
    • 言語別にエントリポイントが違う
    • 一部はランタイムで翻訳してる（単数形・複数形など
  • Webpack Define-plugin
    • 決済フローが異なるのでそれを分けたり
    • Minifyするので不要な分岐は消える
  • a11y
  • 画像の最適化
    • 解像度は購買意欲につながる
    • 最適化ももちろん

BFF

  • クライアントヘビーを回避
  • バックエンドサーバーへの負荷軽減
  • キャッシュ
    • max-ageをみて
  • ロギング
    • セキュアな情報はマスクする
    • HMAC認証
  • リクエストヘッダはパススルーしたり
  • 大変なこともある
    • 後ろのマイクロサービス間のAPIインターフェースが統一されてない
    • キャッシュのパージ
    • 実装待ち

まとめ

  • URLは初期段階できっちり決めるべし
  • リダイレクトもどのレイヤーでやるか早めに
  • SEOはGoogleだけ見るならSPAでもいいのでは
  • ビルド時の出し分けはWebpackのプラグインが便利
  • USではa11y不備は起訴につながる
  • 画像も忘れず最適化しようね

質問

  • Q. BFFでロギングしてるときマスクするセキュアな情報とは？
    • 送り先も自社のマイクロサービスでは
    • A. 個人情報など、ロギングの趣旨に不要なもの
  • Q. 翻訳サービスなど使ってる？
    • A. Excelで国ごとに管理してる
    • 移行したいとは思う
  • Q. WebPとか使ってるけどブラウザ差異はどこまで対応？
    • A. Babelのpreset-envで見てる
    • `picture`タグはフォールバックを用意したり
  • Q. ABテストしてますか？
    • A. まだやってない
    • CMSのレイヤーでやるか、フラグでコンポーネントを出し分けるとか検討中
  • Q. 各国の法律などをフロントエンドエンジニアとして意識したことはありますか？
    • A. カナダなどシビアな国は特に注意して実装してる

すごい知見の塊だった・・！