1 デザインもドメインも違うサイト 上のプレビュー機能をフロントエ ンドのみで実現したらユーザーも エンジニアもハッピーになった話 2020-06-24 ペパボECテックカンファレンス カラーミーショップ プロダクトチーム

2 2 長いタイトルで失礼します

3 3 GMOペパボ EC事業部 カラーミーショップグループ プロダクトチーム 神﨑 拓人 windyakin a.k.a. じゅりあん @windyakin @MITLicense KANZAKI Takuto

4 カラーミーショップ アプリストアについて Section 1 4

5 5 アプリストアについて


6 ● 昨年5月にサービス提供開始 ● カラーミーショップを使う上で便利な機能を｢アプリ｣と してショップオーナー様が手軽に導入できる ● それまで連携機能は各社で開発・宣伝されていた ● ｢アプリストア｣という形でショップオーナー様向けの ショーケースを提供 ● 専用APIやカラーミーショップによる利用料金の回収 6 アプリストアについて カラーミーショップ アプリストア

7 https://app.shop-pro.jp/ 「カラーミーショップアプリストア」で検索！ 7

8 アプリストアと デベロッパーサイト Section 2 8

9 9 プレビュー機能の需要 アプリストアとデベロッパーサイト ● 申請の入力画面上では入力している内容がどこに表示さ れるのかが分かりづらい ● Markdownがどのように表示されるかわからない

10 10 アプリストアとデベロッパーサイト

11 ● アプリの開発に必要なダッシュボード機能を提供 ○ APIを利用するためのOAuth認証に関する基本設定 ○ アプリストアに掲載される内容の「公開申請」 ● アプリストアと同じメンバーが開発・運用をしている ○ ただしアプリストアとデベロッパーサイトは別のリポジトリ ○ 両者とも Nuxt.js(TypeScript) + Vuetify だがバージョンなどに差異 11 アプリストアとデベロッパーサイト デベロッパーサイトとは

12 ● アプリストアへ掲載する情報の更新には審査が必要 ○ アプリストアのアプリ詳細ページは「カラーミーショップ」として 提供・掲載しているのでカラーミー側で内容を把握したい ● デベロッパーが掲載したい内容を「申請」 ○ ここをデベロッパーサイトで掲載したい内容を記入して提出 ● カラーミー側でその内容を「審査」 ● 審査OKであれば公開申請の内容を「反映」できる ○ 公開申請とアプリストアの掲載情報のテーブルは別のもの 12 アプリストアとデベロッパーサイト デベロッパーサイトの「公開申請」

13 13 アプリストアとデベロッパーサイト 
 ショップオーナー様 アプリデベロッパー カラーミーショップ アプリストア (App) デベロッパーサイト (Dev) ①申請 ③反映 ②審査 ④閲覧 アプリストアへ掲載する情報の更新には審査が必要

14 プレビュー機能の開発 Section 3 14

15 15 プレビュー機能の要件 プレビュー機能の開発 セキュリティ ● 入力途中の申請はアプリのデベロッパーのみに表示されるべき秘匿情報 ⏱ リアルタイム性 ● プレビューなので「いま」入力している内容がどうかを確認したい メンテナンスコスト ● アプリページとプレビューを別々に実装してしまうと変更コストが倍

16 16 実装にあたってのいくつかの案 1 プレビュー機能の開発 入力とプレビューがAPIを介して申請内容をやりとりする ● プレビューを行うたびにサーバー側に負荷がかかる ○ リアルタイム性が低い ⏱⬇ ● AppとDevはセッションもログイン情報も異なる ○ プレビューするときにログイン画面を出す必要 ユーザビリティ ⬇ ● 改良としてユーザ認証をJWTでやる案 ○ セキュリティ的にかなり逃げの実装 ⬇

17 17 実装にあたってのいくつかの案 2 プレビュー機能の開発 JWTを発行してそれを使ってAPIから情報を取得する ● 案1の改良型 ● プレビュー時にGETパラメータでJWTを渡す ○ これでApp側のログイン画面は回避できる ○ ユーザビリティの点は回避 ○ ただしセキュリティ的にかなり逃げな実装になりそうなのは明らか ● これもAPIを介する点は変わらない

18 18 実装にあたってのいくつかの案 2 プレビュー機能の開発 Vue.jsのWeb Componentsを使ってDev上に構築 ● Appの更新があるたびにWeb Componentsを作り直し ○ 見た目の細かい修正でも2つのリポジトリに対応する必要がある ○ メンテナンスコストが高い ● Vue.js(Nuxt) や Vuetify のバージョンが違う ○ Web Components導入の知見がチーム内にない ○ もしかしたらできるかも の見切り発車

19 19 実装にあたってのいくつかの案 3 プレビュー機能の開発 window.postMessage + iframe を使う案 ● ページ内の特定のiframeなど任意メッセージを送る機能 ○ 登場したのは2008年で実はIEですら8で対応している古典的機能 https://caniuse.com/#feat=mdn-api_window_postmessage 


20 20 セキュリティ的な懸念の解消のために プレビュー機能の開発 ● window.postMessageはどこからでも送れる ○ 何もしないと関係ないサイトから iframe などでデータを送れる ○ 存在しないアプリページが作れる機能になる ○ セキュリティ的によくない ⚠ ● 送られたデータを受け取るときに送信元を精査 ○ postMessage を受け取るイベントメッセージ中に Origin が含まる 例) event.origin ➡ “https://developer.shop-pro.jp” ○ ここに入る値を設定しているのはブラウザ側なので偽装はできない

21 21 どういった形で実現したか プレビュー機能の開発 ● App側にpostMessageを受け取るページを用意 ○ アプリ個別ページのクラスを継承する形にすることで実装を簡略化 ○ postMessageで受け取ったデータを表示用に整形する ● DevにAppのプレビューページをiframeで表示する ○ postMessageの呼び出しだけDev側にコンポーネントとして実装

22 22 プレビュー機能の開発
 入力画面 プレビュー画面 アプリデベロッパー postMessageで 入力内容を送信 掲載したい内容を 入力 受け取った データを整形 プレビューを表示

23 23 DEMO する時間があるかな？

24 まとめ Section 4 24

25 25 実際に実装・運用してみてわかったこと まとめ 当初の目論見通りメンテナンスコストは低い！ ○ 多少の表示の変更ならApp側のアプリページを編集するだけでOK ○ 新項目の追加はDev側も変更する必要があるがこれは当然 一部の表示はAPI側で計算する必要があった ○ 税込価格の税率をJS側に持たせたくない理由でサーバー側に ○ APIで計算する部分は最後の確認画面でのみで表示するように変更

26 26 まとめ・今後の展開 まとめ ● フロントエンドで柔軟なプレビューの実装ができた ○ postMessage はクロスドメインでのデータのやり取りしたいという ニーズに十分応えられるものだと感じた ● 新カートページにカスタム要素追加した際のプレビュー ○ 何かしらのカスタム要素を追加ができる機能ができたとき ● 新アプリの開発のアーキテクチャとして活用できるかも ○ ショップページに埋め込んだscriptタグとiframeとで連携できそう

27 27 おわり

28 28