GMO Developers Night #10 ペパボ EC テックカンファレンス 2020.06.24 https://pepabo.connpass.com/event/179445/
1デザインもドメインも違うサイト上のプレビュー機能をフロントエンドのみで実現したらユーザーもエンジニアもハッピーになった話2020-06-24 ペパボECテックカンファレンスカラーミーショップ プロダクトチーム
View Slide
22長いタイトルで失礼します
33GMOペパボ EC事業部カラーミーショップグループプロダクトチーム神﨑 拓人windyakin a.k.a. じゅりあん@windyakin@MITLicenseKANZAKI Takuto
4カラーミーショップアプリストアについてSection 14
55アプリストアについて
6● 昨年5月にサービス提供開始● カラーミーショップを使う上で便利な機能を｢アプリ｣としてショップオーナー様が手軽に導入できる● それまで連携機能は各社で開発・宣伝されていた● ｢アプリストア｣という形でショップオーナー様向けのショーケースを提供● 専用APIやカラーミーショップによる利用料金の回収6アプリストアについてカラーミーショップ アプリストア
7https://app.shop-pro.jp/「カラーミーショップアプリストア」で検索！7
8アプリストアとデベロッパーサイトSection 28
99プレビュー機能の需要アプリストアとデベロッパーサイト● 申請の入力画面上では入力している内容がどこに表示されるのかが分かりづらい● Markdownがどのように表示されるかわからない
1010アプリストアとデベロッパーサイト
11● アプリの開発に必要なダッシュボード機能を提供○ APIを利用するためのOAuth認証に関する基本設定○ アプリストアに掲載される内容の「公開申請」● アプリストアと同じメンバーが開発・運用をしている○ ただしアプリストアとデベロッパーサイトは別のリポジトリ○ 両者とも Nuxt.js(TypeScript) + Vuetify だがバージョンなどに差異11アプリストアとデベロッパーサイトデベロッパーサイトとは
12● アプリストアへ掲載する情報の更新には審査が必要○ アプリストアのアプリ詳細ページは「カラーミーショップ」として提供・掲載しているのでカラーミー側で内容を把握したい● デベロッパーが掲載したい内容を「申請」○ ここをデベロッパーサイトで掲載したい内容を記入して提出● カラーミー側でその内容を「審査」● 審査OKであれば公開申請の内容を「反映」できる○ 公開申請とアプリストアの掲載情報のテーブルは別のもの12アプリストアとデベロッパーサイトデベロッパーサイトの「公開申請」
1313アプリストアとデベロッパーサイト ショップオーナー様 アプリデベロッパーカラーミーショップアプリストア(App)デベロッパーサイト(Dev)①申請③反映②審査④閲覧 アプリストアへ掲載する情報の更新には審査が必要
14プレビュー機能の開発Section 314
1515プレビュー機能の要件プレビュー機能の開発 セキュリティ● 入力途中の申請はアプリのデベロッパーのみに表示されるべき秘匿情報⏱ リアルタイム性● プレビューなので「いま」入力している内容がどうかを確認したい メンテナンスコスト● アプリページとプレビューを別々に実装してしまうと変更コストが倍
1616実装にあたってのいくつかの案 1プレビュー機能の開発入力とプレビューがAPIを介して申請内容をやりとりする● プレビューを行うたびにサーバー側に負荷がかかる○ リアルタイム性が低い ⏱⬇● AppとDevはセッションもログイン情報も異なる○ プレビューするときにログイン画面を出す必要 ユーザビリティ ⬇● 改良としてユーザ認証をJWTでやる案○ セキュリティ的にかなり逃げの実装 ⬇
1717実装にあたってのいくつかの案 2プレビュー機能の開発JWTを発行してそれを使ってAPIから情報を取得する● 案1の改良型● プレビュー時にGETパラメータでJWTを渡す○ これでApp側のログイン画面は回避できる○ ユーザビリティの点は回避○ ただしセキュリティ的にかなり逃げな実装になりそうなのは明らか● これもAPIを介する点は変わらない
1818実装にあたってのいくつかの案 2プレビュー機能の開発Vue.jsのWeb Componentsを使ってDev上に構築● Appの更新があるたびにWeb Componentsを作り直し○ 見た目の細かい修正でも2つのリポジトリに対応する必要がある○ メンテナンスコストが高い● Vue.js(Nuxt) や Vuetify のバージョンが違う○ Web Components導入の知見がチーム内にない○ もしかしたらできるかも の見切り発車
1919実装にあたってのいくつかの案 3プレビュー機能の開発window.postMessage + iframe を使う案● ページ内の特定のiframeなど任意メッセージを送る機能○ 登場したのは2008年で実はIEですら8で対応している古典的機能https://caniuse.com/#feat=mdn-api_window_postmessage
2020セキュリティ的な懸念の解消のためにプレビュー機能の開発● window.postMessageはどこからでも送れる○ 何もしないと関係ないサイトから iframe などでデータを送れる○ 存在しないアプリページが作れる機能になる○ セキュリティ的によくない ⚠● 送られたデータを受け取るときに送信元を精査○ postMessage を受け取るイベントメッセージ中に Origin が含まる例) event.origin ➡ “https://developer.shop-pro.jp”○ ここに入る値を設定しているのはブラウザ側なので偽装はできない
2121どういった形で実現したかプレビュー機能の開発● App側にpostMessageを受け取るページを用意○ アプリ個別ページのクラスを継承する形にすることで実装を簡略化○ postMessageで受け取ったデータを表示用に整形する● DevにAppのプレビューページをiframeで表示する○ postMessageの呼び出しだけDev側にコンポーネントとして実装
2222プレビュー機能の開発 入力画面 プレビュー画面アプリデベロッパーpostMessageで入力内容を送信掲載したい内容を入力受け取ったデータを整形プレビューを表示
2323DEMOする時間があるかな？
24まとめSection 424
2525実際に実装・運用してみてわかったことまとめ 当初の目論見通りメンテナンスコストは低い！○ 多少の表示の変更ならApp側のアプリページを編集するだけでOK○ 新項目の追加はDev側も変更する必要があるがこれは当然 一部の表示はAPI側で計算する必要があった○ 税込価格の税率をJS側に持たせたくない理由でサーバー側に○ APIで計算する部分は最後の確認画面でのみで表示するように変更
2626まとめ・今後の展開まとめ● フロントエンドで柔軟なプレビューの実装ができた○ postMessage はクロスドメインでのデータのやり取りしたいというニーズに十分応えられるものだと感じた● 新カートページにカスタム要素追加した際のプレビュー○ 何かしらのカスタム要素を追加ができる機能ができたとき● 新アプリの開発のアーキテクチャとして活用できるかも○ ショップページに埋め込んだscriptタグとiframeとで連携できそう
2727おわり
2828
windyakin
kanamasa
speed1313
10xinc
ivargrimstad
masahiro_nishimi
terukinakano
o0h
kubotak
paper2
a4lg
fendo181
77web
akmur
danielanewman
aarron
eileencodes
trallard
maltzj
pedronauck
stephaniewalter
lara
sferik
maggiecrowley
afnizarnur