Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
デザインもドメインも違うサイト上のプレビュー機能をフロントエンドのみで実現したらユーザーもエン...
Search
windyakin
June 24, 2020
Programming
1
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
2k
Other Decks in Programming
See All in Programming
Jakarta EE meets AI
ivargrimstad
0
1.2k
Figma Dev Modeで変わる!Flutterの開発体験
watanave
0
3.7k
42 best practices for Symfony, a decade later
tucksaun
1
120
カンファレンスの「アレ」Webでなんとかしませんか? / Conference “thing” Why don't you do something about it on the Web?
dero1to
2
160
Haze - Real time background blurring
chrisbanes
1
420
romajip: 日本の住所CSVデータを活用した英語住所変換ライブラリを作った話
sangunkang
0
2.4k
SymfonyCon Vienna 2025: Twig, still relevant in 2025?
fabpot
3
890
Flutterを言い訳にしない!アプリの使い心地改善テクニック5選🔥
kno3a87
3
400
cmp.Or に感動した
otakakot
3
340
Remix on Hono on Cloudflare Workers
yusukebe
2
400
Welcome JSConf.jp 2024
yosuke_furukawa
PRO
0
3k
Missing parts when designing and implementing Android UI
ericksli
0
390
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.3k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
2
250
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
How STYLIGHT went responsive
nonsquared
95
5.2k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.3k
Unsuck your backbone
ammeep
669
57k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.9k
GitHub's CSS Performance
jonrohan
1030
460k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
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