Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
デザインもドメインも違うサイト上のプレビュー機能をフロントエンドのみで実現したらユーザーもエンジニアもハッピーになった話 / How to preview on cross domain
Search
windyakin
June 24, 2020
Programming
1
1k
デザインもドメインも違うサイト上のプレビュー機能をフロントエンドのみで実現したらユーザーもエンジニアもハッピーになった話 / How to preview on cross domain
GMO Developers Night #10 ペパボ EC テックカンファレンス 2020.06.24
https://pepabo.connpass.com/event/179445/
windyakin
June 24, 2020
Tweet
Share
More Decks by windyakin
See All by windyakin
ラブライブ!で学ぶドメイン駆動設計入門
windyakin
1
1.9k
Other Decks in Programming
See All in Programming
CSC307 Lecture 08
javiergs
PRO
0
330
しくじり先生 Image Matching Challenge 2024 編
goosehaaan
0
810
HMSコンペ 11th Solution (team : kansai-kaggler)
t88
1
680
社内 LT 会を発足し、アウトプット文化を醸成させるために考えたこと・やったこと / Starting internal LT meetings and fostering an output culture
mackey0225
3
120
ぼっちを避けて楽しむためのアノテコノテ / Various Tips and Tricks to Avoid Loneliness and Have Fun
nrslib
3
1.7k
みんなのオブザーバビリティプラットフォームを作ってるんだがパフォーマンスがやばい #mackerelio #srenext
ne_sachirou
0
370
DynamoDB コスト最適化っぽいことの基本 with Terraform
kuro_kurorrr
2
250
最近追加した型の紹介とその振り返り
aki19035vc
0
170
Xcode 16のPreviewModifierと@Previewableを活用した効率的なプレビュー方法の考察
ojun9
2
160
さきがけから振り返るアーキテクチャ刷新 / Reflecting on the Architectural Renewal from the Vanguard
nrslib
2
770
Google's Recipe for Scaling (Web) Security – LocoMocoSec 2024
lweichselbaum
0
170
なぜ宣言的 UI は壊れにくいのか / Why declarative UI is less fragile
uenitty
29
13k
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
18
1.2k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
121
18k
In The Pink: A Labor of Love
frogandcode
139
22k
How GitHub Uses GitHub to Build GitHub
holman
471
290k
Making Projects Easy
brettharned
111
5.7k
The MySQL Ecosystem @ GitHub 2015
samlambert
248
12k
Build The Right Thing And Hit Your Dates
maggiecrowley
28
2.2k
Happy Clients
brianwarren
94
6.5k
Automating Front-end Workflow
addyosmani
1362
200k
Art, The Web, and Tiny UX
lynnandtonic
291
20k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
36
9.1k
Transcript
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