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
Multi Step Form, Decentralized Autonomous Organization
pumpkiinbell
1
760
Grafana Cloudとソラカメ
devoc
0
170
1年目の私に伝えたい!テストコードを怖がらなくなるためのヒント/Tips for not being afraid of test code
push_gawa
0
220
『GO』アプリ データ基盤のログ収集システムコスト削減
mot_techtalk
0
130
GoとPHPのインターフェイスの違い
shimabox
2
190
Amazon S3 TablesとAmazon S3 Metadataを触ってみた / 20250201-jawsug-tochigi-s3tables-s3metadata
kasacchiful
0
170
『GO』アプリ バックエンドサーバのコスト削減
mot_techtalk
0
150
昭和の職場からアジャイルの世界へ
kumagoro95
1
380
仕様変更に耐えるための"今の"DRY原則を考える / Rethinking the "Don't repeat yourself" for resilience to specification changes
mkmk884
5
1k
ARA Ansible for the teams
kksat
0
150
メンテが命: PHPフレームワークのコンテナ化とアップグレード戦略
shunta27
0
140
Linux && Docker 研修/Linux && Docker training
forrep
24
4.5k
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.3k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.1k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Building Adaptive Systems
keathley
40
2.4k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
Making Projects Easy
brettharned
116
6k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
12
960
A Philosophy of Restraint
colly
203
16k
Faster Mobile Websites
deanohume
306
31k
The World Runs on Bad Software
bkeepers
PRO
67
11k
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