B2Bサービスが契約時のセキュリティチェックでよく聞かれること(インフラ編)

Engineer Group Manager 兼、SRE Group Managerの前田(@glidenote)です。いつもmemolist.vimを使って頂いてありがとうございます。

B2B向けサービスを提供していると、お客様企業との契約時にサービス、インフラのセキュリティに関する質問表(セキュリティチェックシート)の提出を求められ、少ないところで数十個、多い会社だと数百個のチェック項目がきます。

今回はこれまで数百社のセキュリティチェックに回答してきて、よく聞かれる事項に対し、どのように対応しているかをまとめてみます。 各種レイヤーで対応しておりますが、今回はインフラレイヤーの話になります。

続きを読む

全デバイス・全ブラウザで PDF を読みたい

TL;DR

  • PDF を画面に埋め込む方法は、iframe, object, embed, Viewer(3rd party library の利用)がある。
  • ブラウザネイティブの PDF 表示機能はブラウザ差異が大きいため、PDF を canvas や svg に変換して表示するライブラリやビューアーを利用した方が安定する。
  • しかし 3rd party library / service の利用はバンドルサイズやランタイムでの変換にコストがかかるため、なるべくブラウザネイティブなやり方で PDF を開きつつ、一部ブラウザ向けに対してのみ 3rd party library/service 経由で表示するように分岐させたい。
  • どのブラウザならブラウザネイティブの機能が使えるかを調べるために、サポート範囲の全端末・全ブラウザで PDF の描画結果を比較・調査した。

はじめに

業務委託エンジニアの井手(@sadnessOjisan)です。 今回は KAIZEN Sales の開発で作った "全ブラウザ・全端末対応の PDF コンポーネント" を作るにあたって、PDF の埋め込み方法について調査した結果を紹介します。

先に結果を書くと以下の通りです。

- Chrome
(PC)
Safari
(PC)
Firefox
(PC)
Safari
(SP)
Chrome
(SP)
IE
iframe △(no toolbar) ×(1 枚目のみ) × ×
object △(no toolbar) ×(1 枚目のみ) × ×
embed △(no toolbar) ×(1 枚目のみ) × ×
Google Drive △(不安定) △(不安定)
PDF.js(2.3.2~) ×
PDF.js legacy(2.3.2~) ×
PDF.js(~2.3.2)

KAIZEN Sales の説明と PDF コンポーネントの要件

KAIZEN Sales は企業が商談や営業に使う動画販促資料を管理するプラットフォームです。 その中に顧客企業がリンクを発行して、利用者にそのリンクの中にある動画や画像や PDF を見せてアンケートを取る機能があります。 今回僕が開発していたのはこのリンクで開かれるアンケートページと、そのリンク先にあるアンケートを顧客 HP にそのまま埋め込める 3rd party script です。

big buck bunny
KAIZEN sales の例

(※ Big Buck Bunney is licensed under CC-BY.)

この案件ではユーザーがコンテンツを視聴するページを開発し、その中で PDF を閲覧できるようにしました。ただこの PDF(コンテンツ)表示ページは外部リンクや 3rd party script として広く配布されるため PV も大きくなりやすく、また PC/Mobile や サポート対象の全ブラウザへの対応が必須となりました。

そこで、どの方法を使ってどの端末でアクセスすると PDF が表示されないかを調べるために、実験用の web サイトを作って、いろいろな方法や端末やブラウザを実験していました。 こちらがその実験用のサイトです。

FYI: https://github.com/ojisan-toybox/universal-pdf-component

続きを読む

エンジニアインターンで開発を通して学んだこと

Kaizen Platformでエンジニアインターンをしているyabanaです。

インターン生活全般に関する記事は

インターン生活を振り返って - Kaizen Platform 開発者ブログ

でfunakoshiさんが書いているので、今回は私が実際に行ったKaizen Adというプロダクトの開発についてご紹介します。

Kaizenでエンジニアインターンするとこんなことができるんだ!という参考にしていただけると幸いです。

概要

Kaizen Adは、動画広告を作りたい人(広告主や代理店)が、制作指示書(動画の仕様書に相当するもの)を作成して素材データと共にアップロードすると、GH(Growth Hacker)ネットワークに参加するクリエイターが原則5営業日で動画を制作・納品してくれるサービスです。

Kaizen Ad のサービスサイトはこちら: https://kaizenplatform.com/video

制作指示書の部分には、基本情報、納品期日、制作内容、追加オプション、発注内容の確認、という5つのページがあり、これらの項目名と、現在自分がどの画面にいるのかをステッパーと呼ばれるコンポーネントで表しています。

f:id:kaizenplatform:20210623154658p:plain
赤枠で囲った部分がステッパーです。改修前は制作指示書の各ページの左上に固定されていました。

今回は、このステッパーの改修を行いました。

続きを読む

Kaizen Adのフロントエンドアーキテクチャの遷移について

Kaizen Platformで主にフロントエンドを開発しているyuki-yanoです。
TypeScriptが好きで、最近はZennにDenoでzshのプラグインを作った記事を投稿しました。

今回はKaizen Adというプロダクトにおけるフロントエンドのアーキテクチャの遷移について紹介します。
Kaizen Platformでは2019年に React + GraphQL から成る Kaizen Ad のフロントエンド - Kaizen Platform 開発者ブログ という記事を書いています。
その後、プロダクトが成長するにつれて課題なども出てきており、現在の実装方針は変わってきています。

この記事では現在のアーキテクチャと、どういう経緯があって変遷してきたかについて紹介します。

これまでのKaizen Adでのフロント開発

これまでの実装は 前回の記事 に書いている方針で進めてきました。
基本的にレイヤードアーキテクチャを前提としており、Viewの世界の中だけではなくアプリケーション全体としてView, Usecase, Entityというレイヤを切る規約で強めに縛った設計となっていました。

レイヤードアーキテクチャによる開発は当然様々なメリットもありました。例えば

  • アーキテクチャが共有されていれば誰が書いても近いコードになる
  • ドメインに関わるStateを扱う処理をどこで実装するかが明確(Viewは基本的に関与しなくていい)
  • Serviceのレイヤが抽象化されているのでViewではEntityを取り回すだけで、内部実装などは一切知らなくてよい

などといったものです。

以下が前回の記事で概要の説明に使っていた画像です。
それぞれについての詳細は 前回の記事 を参考にしてください。

20210609115405 20210609115420

現状の課題

プロダクトが成長するにつれて、当時の設計では解決の難しい問題がいくつかでてきました。
具体的に書くと以下になります。

  • レイヤードアーキテクチャの実装手法によるGlobal Stateの肥大化
  • コンポーネントのレイヤリングによる巨大なProps Drilling
  • エンティティの肥大化に伴うGraphQLクエリのサイズ増加

それでは、それぞれの課題の詳細と現在の方針について説明します。

続きを読む