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
デザインもドメインも違うサイト上のプレビュー機能をフロントエンドのみで実現したらユーザーもエン...
Search
windyakin
June 24, 2020
Programming
1
1.2k
デザインもドメインも違うサイト上のプレビュー機能をフロントエンドのみで実現したらユーザーもエンジニアもハッピーになった話 / 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
2分台で1500examples完走!爆速CIを支える環境構築術 - Kaigi on Rails 2025
falcon8823
3
3.6k
CSC305 Lecture 06
javiergs
PRO
0
230
PHPに関数型の魂を宿す〜PHP 8.5 で実現する堅牢なコードとは〜 #phpcon_hiroshima / phpcon-hiroshima-2025
shogogg
1
220
技術的負債の正体を知って向き合う / Facing Technical Debt
irof
0
170
組込みだけじゃない!TinyGo で始める無料クラウド開発入門
otakakot
0
270
デミカツ切り抜きで面倒くさいことはPythonにやらせよう
aokswork3
0
230
CSC509 Lecture 03
javiergs
PRO
0
340
Flutterで分数(Fraction)を表示する方法
koukimiura
0
130
そのpreloadは必要?見過ごされたpreloadが技術的負債として爆発した日
mugitti9
2
3.4k
Web Components で実現する Hotwire とフロントエンドフレームワークの橋渡し / Bridging with Web Components
da1chi
3
2.5k
20251016_Rails News ~Rails 8.1の足音を聴く~
morimorihoge
1
280
ソフトウェア設計の実践的な考え方
masuda220
PRO
4
580
Featured
See All Featured
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Statistics for Hackers
jakevdp
799
220k
Writing Fast Ruby
sferik
629
62k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
3.7k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
870
Optimising Largest Contentful Paint
csswizardry
37
3.5k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Context Engineering - Making Every Token Count
addyosmani
6
250
How STYLIGHT went responsive
nonsquared
100
5.8k
Balancing Empowerment & Direction
lara
4
690
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
115
20k
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