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.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
Effective Signals in Angular 19+: Rules and Helpers @ngbe2024
manfredsteyer
PRO
0
130
モバイルアプリにおける自動テストの導入戦略
ostk0069
0
110
rails stats で紐解く ANDPAD のイマを支える技術たち
andpad
1
290
RWC 2024 DICOM & ISO/IEC 2022
m_seki
0
210
ゆるやかにgolangci-lintのルールを強くする / Kyoto.go #56
utgwkk
1
370
クリエイティブコーディングとRuby学習 / Creative Coding and Learning Ruby
chobishiba
0
3.9k
なまけものオバケたち -PHP 8.4 に入った新機能の紹介-
tanakahisateru
1
120
CSC509 Lecture 14
javiergs
PRO
0
140
Итераторы в Go 1.23: зачем они нужны, как использовать, и насколько они быстрые?
lamodatech
0
710
たのしいparse.y
ydah
3
120
見えないメモリを観測する: PHP 8.4 `pg_result_memory_size()` とSQL結果のメモリ管理
kentaroutakeda
0
310
DevFest Tokyo 2025 - Flutter のアプリアーキテクチャ現在地点
wasabeef
5
900
Featured
See All Featured
Navigating Team Friction
lara
183
15k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
Designing for humans not robots
tammielis
250
25k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Producing Creativity
orderedlist
PRO
341
39k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.6k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
Visualization
eitanlees
146
15k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
"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