n.nikushiの記事一覧

WebpackerをやめるならWebpackManifestというgemが便利、という話

先日、社内のSlackでpixivさんのブログ記事 今日から簡単!Webpacker 完全脱出ガイド がシェアされてて、『あっ、これは…弊社でもやったやつではないか。』とおもいました。Webpackerは便利なんですけどね。

本記事はこのpixivさんのポストを受けて WebpackManifest というgemを紹介します。

ラクスルでのWebpackerを辞めた経緯

  • もともとWebpackerを使った管理画面プロジェクトがあった
  • そこにECサイトも乗せるようなった
  • package.jsonは管理画面、ECサイトで分けて管理したかった
  • Webpackerは1個のpackage.json、1個のwebpackコマンド、1個のmanifest.json前提の作りなので、package.json分けて複数のwebpackビルド処理系を作りたいラクスルの用途に合わなかった => 脱Webpacker

pixivさんのブログで紹介されてるとおりで、manifest.json を Rails に組み込むための view helper が必要になったので、弊社内でも lib/ 以下に小さなライブラリを作っていました。

gem化

そして、社内で他にもRailsアプリが立ち上がりだしてきて、『そろそろ、gem化せななあ』とおもっていたところにこのpixivさんの記事でしたので、本記事執筆にあたって WebpackManifest というgemにしました。rubygemsよりインストール可能です。このgemを使うとwebpackerを使わずに webpack の webpack-manifest-plugin が出力するmanifest.jsonに従ってview helperが asset のパスやscriptaタグをrenderingしてくれるようになります。

もともとの社内にあった view helperのメソッド名よりpixivさんのメソッド名のほうが適切でしたので、ヘルパー実装部分はpixivさんの実装を参考に組み込み直しました。

使い方

  • Webpacker gem のアンインストール
  • 代わりになる webpack.config.js の作成
  • 素のwebpackの webpack-manifest-plugin を用いて manifest.json を出力する
  • WebpackManifest gemをインストールし、↑のmanifest.jsonのパスをセットする(詳細はgemの README を参照する)
  • gem付属のview helperを使う

という流れになります。

不具合等ありましたらPRいただければとおもいます。

まとめ

WebpackManifest というgemを使ったWebpackerをやめる方法をご紹介しました。

ラクスルではエンジニアを絶賛募集してます

ご興味ありましたらどうぞオフィスへ遊びに来てください。

 

1週間やる、楽しい社内ハッカソンの作り方。

RakSul Hack Week Logo

はじめに

こんにちは。ラクスルプラットフォームチームのエンジニアの二串です。

先日、ラクスルではRaksul Hack Week #1という1週間通しでやる全員参加型の社内ハッカソンを開催しました。その運営を担当しまして、本記事では1週間やる楽しい社内ハッカソンの作り方をご紹介します。

開催の背景

もともとラクスルのエンジニア向けの制度としてHack-It Dayという月に1日、自由なテーマで開発することができる日がありました。もちろん活用はされていたものの、1日では満足いくものが作れなかったり、日々のリリースを優先してしまったり…といった課題も見えてきていました。そこで今回「Raksul Hack Week」に名称を改め、皆で1週間集中して面白いプロダクト・サービスを作ったり、新しい技術チャレンジをしたりする機会をつくろうと考えました。

第1回目となる今回のテーマは「HACK THE SYSTEM, HACK THE WORLD. (仕組みをハックすれば、世界はもっとカッコよくなる)」です。1週間通しでハッカソンをやる、というのは個人的に(そして他のエンジニア達も)初めての体験でありましたが、結果として自分たちの設定したテーマに全力を注ぐことができてよかったと思います。取り組んだ内容は記事後半の方で紹介します。

イベント概要

どんな感じのイベントだったのか?

  • 参加者はエンジニア、プロダクトマネージャー、デザイナーとする
  • ハッカソンの期間は1週間とし、期間中はハッカソン100%コミット、普段の開発業務はやらない(※ ただし緊急対応系は最優先で)
  • チーム制とする
  • 最終日に各チームは成果発表する
  • ラクスルの事業、ステークホルダーに関わることであれば何に取り組んでも良い

開催週の月曜日が祝日のため実際には前3日間開発、4日目成果発表会となりました。開催場所は企画段階で社外のコワーキングスペース等を借りるという案も出ましたが、初回ということで慣れたオフィス内開催としました。

準備

参加者の自発性を重視する形で、チーム構成は自由、また取り組む内容もチーム毎に自由に決定可能としました。また、イベント開催1ヶ月以上前から、各自で取り組みたいことを考えてもらってアイデアを膨らませてねーとお願いし、少しつづ Hack Week を盛り上げることにしました。

今回やったチームを決めるまでの流れは次の通りです。

  1. まず、社内(非参加者方面)からネタ(お困り毎など)を募集する
  2. 1を参加者に展開してアイデアの種にしてもらう
  3. 参加者は各自やりたいことをシェアする(専用confluenceページに書いてもらう)
  4. 出たやりたいことに賛同した人たちでチームを組む、もしくは3の起票者がメンバをリクルーティングしたりして組んでもらう
  5. チームを決めかねてる人たちはシャッフルで決定。取り組み内容は3を参考に決めてもらう
  6. Google Formでチームエントリ

全チーム構成が決まったのが開催の1週間前でした。この時点で大体のチームがやることもざっくり決めれている状態でした。

普段の業務に近いメンバーと組んだチームもありましたが、結構普段組まないメンツでの構成のチームもあり、結果的には何が出来上がるかな〜と期待が膨らんでくるチーム編成となりました。

ステッカー作りました(もちろんラクスルで作りました)

ハッカソン当日

ハッカソンが始まってしまえばあとは各チームもくもくと作業するだけです。社内の様々な場所で開発が行われました。

ちなみに、私は運営ではありましたがチームの一員としても参加しており期間中はがっつりと開発してイベントを楽しむこともできました。事前の準備が大事! 普段はサーバサイドの開発がメインですがHack Weekでは違う技術をということでTypeScriptNuxt.jsでフロントエンド中心のプロジェクトをやりました。難しかったですが勉強になりました!

ちなみに、1日の終わりに各チーム進捗報告をSlack #hack_week チャネルにしてもらうようにしました。進捗サマリとともに開発風景やスクショ等を共有してもらうことで、チーム間でもコミュニケーションが生まれたり、ビジネスメンバ等も様子を垣間見れたりして良かったとおもいます。

CTO泉率いるチームの開発風景。なんか楽しそうです。

 

ベトナムの開発拠点もリモート参加

取り組み内容紹介

一部ではありますがアウトプットを紹介します!

Fax2Web

アナログとデジタルとのブリッジになるための技術開発、ということでFAXとwebをつなぐチャレンジ。FAXを受信するとシステム連携されwebの注文ステータスが変更されたり、文字認識により自動入力されたりする仕組みのPoCを取り組みました。

メンテゲーム

サイトのメンテ中に遊べるゲームの実装にトライ。システム構成は Vue CLI 3 を使った静的サイト。

発表会・打ち上げの様子

発表会は1チームづつ順に発表。ベトナムの開発拠点とも接続して中継しました。

発表会の様子

 

1週間のハッカソンを振り返って話題が尽きない打ち上げとなりました

その他細かい運営のこと

参加必須のため参加者が50人弱ということでそれなりに入念に準備しました。まず、各チームの開発繁忙期と被らないようにスケジュール調整し日程を決めました。その後は運営コアメンバを招集してのキックオフ(これが開催3ヶ月前)、あとは週1回定例会を開きまして、少しづつ準備進めていきました。

なお、企画にあたっては以下の記事を参考にさせていただきました。有益な情報ありがとうございました。

まとめ

Raksul Hack Week #1 という社内ハッカソンを開催しました。

初めての長期社内ハッカソンということで、開催前には本当に盛り上がるのだろうか、普段1週間開発を止めてまでやるほどの価値が出るだろうか、といった不安も運営的にはありましたが、結果的には開催後のアンケートや、また経営陣へのイベント後の振り返り報告でも好評で良いイベントになりました。

普段の業務では要件通りに仕事をするということは大切ではありますが、今回のようにエンジニアやデザイナーの自発的でクリエイティブな発想で仕事をするというのも価値があることだなと感じました。また、使ったことのない技術スタックを試す機会としても良かったとおもっていて、実際今回使った新しい技術を業務に取り入れることにしたチームもありました。

今後もラクスルのテックカルチャーの1つとして開催していければいいなとおもいます。

社内ハッカソンイベント Raksul Hack Week #1 を開催中です

RakSul Hack Week Logo

エンジニアの二串です。

最近少しづつ朝晩が冷えるようになってきて秋の到来を感じますね。さて、秋といえばハッカソンですよね(!!?)

というわけで今週、ラクスルでは社内ハッカソンイベント「Raksul Hack Week #1」 を開催しています。

RakSul Hack Weekとは?

もともと月に1日、エンジニアは直接的な業務を離れ自由に開発をしていい Hack It Day という制度がありました。今回はそれを拡張し、1週間に渡って、全社的に(エンジニア、プロマネ、デザイナー混ぜて)やろうよ!というイベントです。さらりと書きましたが、1週間普段の開発を止めて、自由な発想でおもいっきりやってみる企画になります。今回が記念すべき(?)第1回目となります!!!

今回はやりたいことを事前にメンバーから集めて、出てきたアイデアをベースに数名1チームでチームを組んで、チーム=プロジェクトを作って取り組む方式を採用しました。

今週はシルバーウィークで月曜がお休みなので火曜から金曜まで計4日間の開催し、最終日にはチームごとの成果発表を開催します。成果発表会では、参加者の他、非参加者(ビジネスやカスタマーサポート)も交えての会となります。

楽しく作戦会議中の様子

各チームで作業が進んでます

今回は1週間ということで普段なかなか試せない技術スタックを試してるチームも多く、参加者達はそれぞれ盛り上がって来ているようです。

どんなことをやってるの?

例えば、

  • AWS lambda を使ってのFAXとウェブをつなげるサービスの開発
  • Nuxt.js + TypeScript で作るSlackと連携したウェブサービス
  • AIによる注文審査の自動化システム

などなど…. 技術領域も解決する課題も様々。今回は12チーム、総勢41名が参加しています。

もくもく作業中!?

さて、どんな成果物ができるでしょうか!!? 今から楽しみです。

また詳細はレポートします。

運用中のRailsプロジェクトをなめらかに複数DB化した話

エンジニアの二串です。

ラクスルのRailsのプロジェクトではデータベースとして Amazon Aurora(MySQL) を採用しています。そしてO/Rマッパーとして当然ActiveRecordを使っています。

さて、ActiveRecordを使っていて悩むのが複数DBの接続ですがみなさんはどうしていますか? ActiveRecordは標準では1つのデータベースにしか接続できないので、複数の異なるデータベースサーバや、マスター・リードレプリカの接続を切り替えるには工夫が必要です。しかし、世の中には素晴らしい方々がいて複数DB切り替えを可能にするgemが提供されています。

今回はそれらgemの中からSwitchPointを採用し、運用中のRailsプロジェクトになめらかに導入したときの経緯と方針、さらに具体設定を紹介します。

確認したバージョンは以下のとおりです

  • Rails 5.1.5
  • Ruby 2.4.2
  • switch_point 0.8.0
  • arproxy 0.2.3

最初からまとめ

記事では以下のことを書いています。

  • 運用中のRailsプロジェクトにSwitchPointを導入し複数DB化しました
  • マスター接続をデフォルトにし、オプショナルでリードレプリカへ接続するようにしました
  • 複数DB化した後も、いままでの素のRails(シングルDB運用)での開発のスピード感を損なわないよう、工夫をしました

導入前の事情

複数DB化の背景を少しだけお伝えしますと、今回のRailsプロジェクトは元々はphpで書かれた管理画面の刷新目的でスタートしたプロジェクトでした(詳しい事情は過去の記事でも触れています)。しばらくの月日の後、プロジェクトがいい感じに育ちまして表側の機能も提供するまでに進化しました。現在では、そうだ、ラクスルを作り直そう!でも触れられているRaksul Platform Projectの1コンポーネントを担っています。

今回の対応はその表側の機能も提供することになったフェーズでの話で、状況は以下のとおりでした。

  • これまで管理画面のみを提供していたので、マスターのみの接続で割り切ってた
  • 今後、raksul.comのパブリックな機能も提供することになった
  • read mostly, write sometimesなサイト特性上、参照系はリードレプリカへ逃したほうがベターだが、マスターに向けてしまっても当面は捌ける規模感
  • とはいえ、マスターの負荷を増加させないようリードレプリカへの接続も用意しておきたい

このような経緯で複数DB化の対応を入れることにしました。

複数DB化によるマイナス面の考慮と導入方針

これまでの経験上、複数DB化することにより以後の開発スピードが落ちたり、運用工数が増えるケースがあることを知っていました。具体的には、

  • 実装工数増加(この save! はマスターに接続して、次はSELECTするからリードレプリカに接続して…と考えたりする工数)
  • コードの見通しが悪くなる(SwitchPointの場合 with_readonly { with_writable { ... } } のようにブロックで囲ってネストするので)
  • テストの実装工数(同上 + FactoryBotで作成する際の考慮等)
  • レプリ遅延の考慮が発生する (INSERT直後にリードレプリカ側でSELECTして空振ったら、マスターにフォールバックして参照する、レプリ遅延を考慮したCI環境にするかどうか、etc..)

等々。

これらのデメリットを受け入れるというのも一つのやり方ですが、そうはしたくありませんでした。なるべく開発スピードを素のRailsでの感覚のまま、これまでのシングルDBオンリーでの開発のスピード感のままに、複数DB化できないだろうか、という点をとても大事にしました。

また、改修にあたっては、既に管理画面向け機能がたくさんあるのでコードの修正範囲は最小にしようとおもいました。

そこで、改修にあたって以下の方針を立てました。

  • gemはSwitchPointを使う
  • マスターDBデフォルト、リードレプリカ参照をオプショナル
  • コントローラのアクション単位で参照を切り替る
  • レプリ遅延を考慮したコードは書かないようにする
  • RAILS_ENV=testではシングルDBで
  • マスター・リードレプリカ接続状況をログに記録する

以下でそれぞれ詳細説明します。

SwitchPoint

SwitchPoint 1択でした。理由は、私の前職のプロジェクトで使っていて問題なく動いているのを知っていたのと、そのときに内部実装を大体把握していたからでした。よって他のgemは検討しませんでした。

マスターDBデフォルト、リードレプリカ参照オプショナル

SwitchPointのREADMEを読み進めると、モデルクラスはマスター、リードレプリカどちらに接続するかを with_readonly {} または with_writable {} ブロックでどちらも指定した例に見られます。この方針で進めると、我々の場合既存の管理画面のコントローラをすべて修正しなければならなくなってしまいます。コードの改修量は最小にしたかったのでこれは避けたい。

そこで、まず、with_readonly {}with_writable {} も指定せずにActiveRecordでクエリを実行した場合はデフォルトでマスターに接続されるようします。そして重いクエリが実行されるページやアクセスが多いページでは都度 .with_readonly {} を使ってリードレプリカへ接続させるようにしました。

# こういう処理が既にあって...
Order.find(params[:id]).update!(order_params)

# 素で SwitchPoint を導入すると以下のような書き換えが必要だが...
order = nil
order = Order.with_readonly { Order.find(params[:id] }
Order.with_writable { order.update!(order_params)

# そうではなくマスター接続をデフォルトにすれば、既存コードを書き換えずに済む
Order.find(params[:id]).update!(order_params)

これを実現するにはいくつか設定が必要です。READMEにはあまり書かれていなかったので内部実装も読んでます。

database.yml

# writable 系は Rails 標準のネーミング development, production, etc とする.
# これは https://github.com/eagletmt/switch_point/issues/16 の通りで、標準のネーミングの設定が無いと
# Rails が起動しないケースに遭遇したため.
development:
  # 接続情報(略)
  database: raksul_development
development_raksul_readonly:
  # 接続情報(略)
  database: raksul_development

test:
  # 接続情報(略)
  database: raksul_test
test_raksul_readonly:
  # 接続情報(略)
  database: raksul_test

production:
  # 接続情報(略)
production_raksul_readonly:
  # 接続情報(略)
  • マスターの接続情報はRails標準のdevelopment,test,productionに定義する
  • リードレプリカの接続情報は#{Rails.env}_raksul_readonly に定義する

switch_pointの設定

SwitchPointでマスターDBへの接続をデフォルトにするには SwitchPoint.writable!(接続シンボル名)をアプリケーション初期化フェースでcallします。

# config/initializers/switch_point.rb

SwitchPoint.configure do |config|
  raksul_config = {
    readonly: :"#{Rails.env}_raksul_readonly",
    writable: :"#{Rails.env}"
  }
  if Rails.env.test?
    # 通常SwitchPointは2本コネクションを作る(readとwrite).
    # しかし、database cleanerでtransaction strategyを使っているとテストがfailする.
    # なぜなら、transactionのbeginはwriteコネクションでcallされ、
    # SELECT は read コネクションで呼ばれるが、
    # FactoryBotで作られたレコードはcommitされるまでSELECTしても参照できないのでテストが成立しない.
    #
    # この問題を解決する2つの方法:
    #   1. RAILS_ENV=testでのみSwitchPointのコネクションを1本にする
    #   2. transaction以外のstragegy(truncation or deletion)に変更する
    #
    # 我々は1を選択した。2の方法ではテストが遅くなったため。
    #
    # 1をやるには、readonlyのコネクション設定を消すことで実現できる.
    # こうするとSwitchPointはwritableコネクションにフォールバックする挙動
    # ref https://github.com/eagletmt/switch_point/blob/v0.8.0/lib/switch_point/proxy.rb#L131
    raksul_config.delete(:readonly)
  end
  config.define_switch_point :raksul, raksul_config
end
# Change @global_model of the proxy for raksul :writable
# ブロック指定なしの場合の挙動を writable にする
SwitchPoint.writable!(:raksul)


# app/models/application_record.rb
class ApplicationRecord < ActiveRecord::Base
 self.abstract_class = true

 # モデルのSwitchPoint組み込み
 use_switch_point :raksul
end

なお、一点database_cleanerでtransaction strategyを使っていたので上のコメントの通りコネクションを1本にする対策を入れました。

これで既存のコードは修正せずに済みます。

ではリードレプリカを参照したい場合には with_readonly { } のブロックを書かなければならないのか? これも次の方法で楽をします。

コントローラのアクション単位でリードレプリカに切り替える

開発ポリシとして、コントローラのアクション単位でリードレプリカへ接続を向けるようにします。

例えば、OrdersControllerの #index, #show, #new, #edit ではDBへの書き込みはなく参照しか発生しない、というケースは良くあることかとおもいます。なので、around_action filter を使って with_readonly {} をcallしてあげます。そうすることで、リードレプリカ参照においても with_readonly {} のブロックを意識することなく filter を設定するだけで済みます。ブロックがないのでコードの見通しが損なわれません。

class ApplicationController < ActionController::Base
  private

  def with_readonly
    ApplicationRecord.with_readonly { yield }
  end
end

class OrdersController < ApplicationController
  around_action :with_readonly, only: %i[index]

  def index
    # アクション内で .with_readonly { .. } を意識しなくて済む
    @orders = Order.all.order(:id)
  end
end

中には参照系のペーシだけど別途行動ログを書き込みたいといった場合もあるかもしれませんが、そういうケースではそのそのアクションではリードレプリカへ接続させずマスターへ接続させる、で割り切ります。

レプリ遅延は考慮しないコードを書く

1つのアクション内でいくつかレコードをSELECTしINSERT or UPDATEする時、理想的には参照はリードレプリカへ、書き込みはマスターへ、と細かく切り替えるのがDB負荷を考えると理想的です。ただ、レプリ遅延により書き込み直後のリードレプリカ側のSELECTが空振って想定してなかったバグが発生したり、またその対策としてマスターへフォールバックさせるコードを書いたり…という経験がある方もいるとおもいます。このような状況では開発工数も運用工数も増えます。

そう、この考慮したくない、そうおもいました。ですので思い切って割り切ることにしました。つまり、書き込みが発生するアクション内ではずっとマスターと接続させておく。こうすることでレプリ遅延しても同じアクション内でレプリ遅延は発生しないので考慮する必要はなくなります。(リダイレクト先のアクションでレプリ遅延がある可能性はありますが)

トラフィック特性上、更新系のアクションをマスターに向けても即座に詰まることはないので、これで良いと思っています。もし、トラフィックが激増して厳密に切り替えないと回らない…という状況になったら対策するとして、そうなったときはつまりサービスが拡大しているということなのでとても嬉しい状況ですね。

RAILS_ENV=testではシングルDBで

上述の通り、レプリ遅延を極力考慮しない割り切りなので、テスト実行においてレプリ遅延が発生するケースをあぶり出すような考慮はしません。ですのでCI環境やローカル環境ではシングルDBなのでレプリケーション設定もしてません。

マスター・リードレプリカとの接続状況をログに記録する

開発時に便利なので、ActiveRecordのクエリログに readonly or writable どちらに接続したかを記録するようにしました。ログの拡張には cookpad/arproxy を使いました。とても便利で感謝しかないです。

設定

# config/initializers/arproxy.rb

if Rails.env.development? || Rails.env.test?
  require 'switch_point_logger_enhancement'

  Arproxy.configure do |config|
    config.adapter = 'mysql2'
    config.use SwitchPointLoggerEnhancement
  end
  Arproxy.enable!
end

# lib/switch_point_logger_enhancement.rb

class SwitchPointLoggerEnhancement < Arproxy::Base
  def execute(sql, name = nil)
    proxy = SwitchPoint::ProxyRepository.checkout(:raksul)
    mode = proxy.mode
    name = "#{name} [#{mode}]"
    super(sql, name)
  end
end

 

ログサンプル

SCHEMA [readonly] (0.8ms)  SHOW FULL FIELDS FROM `tickets`
Ticket Load [readonly] (0.3ms)  SELECT `tickets`.* FROM `tickets` WHERE `tickets`.`staff_id` IN (100, 201, 12, 13, 71, 10)
Staff Load [writable] (0.3ms)  SELECT  `staffs`.* FROM `staffs` WHERE `staffs`.`id` = 2 ORDER BY `staffs`.`id` ASC LIMIT 1
Role Load [writable] (0.4ms)  SELECT `roles`.* FROM `roles` INNER JOIN `abilities` ON `roles`.`id` = `abilities`.`role_id` WHERE `abilities`.`staff_id` = 2

[readonly] [writable] の箇所です。

まとめ

運用中のRailsプロジェクトにSwitchPointを導入し複数DB化しました。

マスター接続デフォルト、リードレプリカ接続をオプショナルとすることで、既存コードの改修を最小に押さえて導入の敷居を下げつつ、リードレプリカを参照させるときはコントローラのアクション単位で制御するようにしました。

また、レプリ遅延の考慮は極力意識しなくて済むよう、マスター、リードレプリカの接続を混ぜるアクションを実装しない割り切りをしました。

これらにより、複数DB化した後も、素のRails(シングルDB運用)と同じレベルの開発スピード感を維持することができました。

実際、本番導入からしばらく立ちますが問題なく運用できており、また開発もこれまでどおりのスピード感で進めれています。

ラクスルではエンジニアを積極採用しています

いろいろ詳しく書きましたが、複数DB化にあたっての検討は私一人で行ったわけではなく、自社のサービス傾向や開発運用スタイル似合うかどうかを、周りにいるRailsに詳しいエンジニアにも相談しながら、進めていきました。1人で決めるより話し合って決めるラクスルのスタイルはとてもやりやすく感じています。

そういうわけでして、ラクスルでは私達と開発指針を議論しながら開発したいエンジニアを絶賛募集しています。是非一度オフィスに遊びにきてください!

iframe で複数の管理画面を1つの統一されたサイトに見せるパターンのまとめ

こんにちは。エンジニアの二串です。普段はサーバサイドの開発をしていますが、今日は最近仕事で取り組んだフロントよりの話になっています。

iframe を使って複数の管理画面サイトをあたかも1つの統一されたサイトとして見せるパターンをまとめます。

iframe を使って別サイトをはめ込むことは簡単ですが、実際複数ページあるサイトをはめ込もうとすると、ただ iframe を使うだけでは力不足です。例えばiframe内でのページ遷移、高さ調整、パーマリンク等で問題を感じます。

今回紹介する tips のいくつかはインターネット上で見つけられますが、今回の複数管理画面を1つにマージするという視点でまとまった記事は見つけられなかったので、まとめたら便利なのではとおもい記事にまとめました。

コードスニペットを以下で掲載していますが、より詳しくはデモアプリも併せて見ていただければとおもいます。

背景

移行イメージ

ラクスルに存在する最もレガシーなシステムは admin と呼ばれるいわゆる管理画面です。PHPで作られています。そのレガシー管理画面を素早く新システム(Ops Rails製)へ移行する必要がありました。

当時の状況としては

  • 新管理画面はまだ機能が少ないが、今後の新規開発は新管理画面でしたい
  • 旧管理画面には多くの機能がまだあり、理想的には新管理画面に移植したいものの、工数的にさくっと移行できない
  • オペレーションの中心は旧管理画面から新管理画面に移行してしまいたい

というような状況でしたので、iframe を使って新管理画面の1機能として、旧管理画面の各ページを埋め込んでしまって、ユーザー目線での移行については少ない工数で完了させることにしました。

iframe埋め込みによる問題点

単に iframe の src 属性に URL を指定すると、以下の点が課題になります。

  • 旧管理画面のページ数は多いので、ページごとに iframe を設置するのは大変
  • iframe の高さ動的に変えれない(初期ページや子側でページ遷移した場合)。結果的にページが切れる
  • ブラウザアドレスバー問題
    • 子側でページ遷移を何回かした後に F5 を押すと元に戻る。またURL を他の人にシェアできない。
  • 子側ページ内のリンクが 旧管理画面URL 問題
    • リンク先 URL を Slack 等でシェアできない(できるけど iframe が外れる)
    • 別タブで開くと iframe が外れる
  • そもそも、デザインの統一性がない(子側のヘッダやサイドバーメニューが邪魔)

さらに補足すると、今回の2画面はドメインが異なるため、iframeの親・子間で window をまたいで javascript や css で操作しようにもクロスドメイン(CORS)のため DOM 操作できません。

仕組み全体像

以上の問題を踏まえ、以下の指針を立てました

ページ表示の流れ

  • 新管理画面側(Rails)では `GET /proxy?path=path/to/page` というエンドポイントを作り <iframe src=”https://旧管理画面/path/to/page”> をレンダリングする。つまりどんなページもはめ込むことができる。
  • 親・子それぞれに今回のための javascript  を設置し(parent.js, child.js)、window間通信は window.postMessage() API を使う。これによりクロスドメインであってもwindow間で通信可能
  • この通信路を使って子の page height などを 親に伝える。高さ以外の情報もあるので、メッセージタイプ(type)、メッセージデータ(data)を含めた object をデータペイロードに入れて送ることにする。
  • iframe内のリンクの諸々の問題は、a タグの href の値を力技で新管理画面のproxy URL に書き換える。
  • サポートブラウザは Google Chrome のみとする。社内利用のツールなので工数削減も踏まえ割り切れる点と、そもそも社内で Google Chrome が標準で使われているので。

以下、長くなりますが、1つずつ見ていきます。

GET /proxy?path= エンドポイント

# app/controllers/proxies_controller.rb
class ProxiesController < ApplicationController
  def show
    path = params[:path] || ''
    @src = 'https://旧管理画面FQDN/' + path
  end
end

# app/views/proxies/show.html.erb
<iframe id="proxy-iframe" src="<%= @src %>" height="1024" style="overflow: hidden; border: none;" scrolling="no" frameborder="no"></iframe>

# config/routes.rb
get '/proxy', to: 'proxies#show'
  • GETパラメタの path から旧管理画面の URL を構築し iframe の src 属性へセット
  • height=”1024″ は初期値として。後述の方法で別途ページ毎に動的に変える。
  • その他、iframeのボーダー枠線。スクロールバーを消す。これはiframeっぽさを無くすための工夫
  • id属性 `proxy-iframe` は後述の javascript の処理で利用

これで旧管理画面の任意のページを新管理画面で扱えるようになりました。

なお、旧管理画面側が X-Frame-Options を返却していたので iframe 内で表示させるため nginx で消しこみました。

親・子window間通信

新・旧管理画面それぞれに以下の javascript を置きます。今回のケースでは、子から親に一方通行でメッセージを伝え親側でアクションさせればよかったので、子と親の通信はいわゆるクライアントサーバモデルになっています。

子側

const postMessage = (type, data) => {
  const rawData = JSON.stringify({ type: type, data: data })
  window.parent.postMessage(rawData, '*')
}

// iframe内でレンダリングされた場合にのみ発火させる
if (window !== window.parent) {
  window.addEventListener('load', () => {
    // 子の高さを親に伝え、親の iframe の heigit を変更
    postMessage('PageHeight', {height: document.body.scrollHeight})
  }, false)
}
  • iframe 内でレンダリングされた場合にのみ実行している
  • on load 時に高さを送る。メッセージには type と data がありJSON シリアライズして送る。

iframe 内でレンダリングされた場合にのみこの仕組が発動するようにすることで、移行をやりやすくしました。旧管理画面直アクセスでは発動しないので、旧管理画面直アクセスへのパスを残しつつ、緩やかに移行を進めれます。

親側

const messageHandlers = {
  PageHeight: (data) => {
    // iframe の height を調整
    let elm = window.document.getElementById('proxy-iframe')
    elm.style.height = `${data.height}px`
  }
}

window.addEventListener('message', (event) => {
  console.log('[ops] message received', event)

  // On development environment webpack-dev-server sends message, so skip message from it.
  if (/^https?:\/\/(localhost|127.0.0.1)/.test(event.origin)) return

  // Verify received message from for security manner of postMessage() API,
  const originRe = /旧管理画面URL/
  if (event.origin.search(originRe) === -1) {
    console.log('Blocked the message from ' + event.origin)
    return
  }

  const data = JSON.parse(event.data)
  if (data.type === null) throw new Error('[ops] Message received, but no type specified')
  if (!messageHandlers.hasOwnProperty(data.type)) {
    throw new Error(`[ops] Message received, but type "${data.type}" is invalid`)
  }
  messageHandlers[data.type](data.data)
})

細かいエラーハンドリングも載せましたが、中心は以下のとおりです。

  • window.postMessage() で送信されたデータは ‘message’ イベントで受け取れる
  • type に対応するメッセージハンドラ関数へディスパッチする
  • PageHeight ハンドラでは iframe の height 属性を変更

iframe高さの動的調整

1つ前のセクションのとおりです。

ブラウザアドレスバー問題

iframe内でページ遷移を繰り返してもブラウザアドレスバーのURLは最初のURLのまま問題。実際のカスタマーサポートなどの現場では、「あ、この注文、サポートが必要そうだから Slack で注文詳細のURLをシェアしておいて…」 といったことありますので、iframe内で遷移したあとの URL も気軽に貼り付けれる必要がありました。

そこで、子の a タグのクリックイベントを prevent default  で止めて、PageMove メッセージを送り、親側windowでページ遷移させてしまうことにしました。詳しくはサンプルアプリのコードを参照ください。

なお、a タグ以外に POST 等の後のサーバサイドでのリダイレクト処理される場合にも同様の課題はあります。管理画面の特性を検討した結果、リダイレクトについては特に何も対策せずとも運用上なんとかなると判断してます。

子側ページ内のリンクが 旧管理画面URL 問題

リンク先をシェアされたり、別タブで開こうとすると iframe が外れてしまう。

これに対しては、子側の DOMContentLoaded で hrefの属性値を 新管理画面の proxy URL に挿げ替えてしまうことにしました。

const fakeAnchors = function () {
  document.querySelectorAll('a').forEach(function (elm) {
    // getProxyUrlFromAdminUrl() は https://旧管理画面FQDN/foo/bar を
   // https://新管理画面FQDN/proxy?path=foo/bar に変換
    elm.href = getProxyUrlFromAdminUrl(elm.href)
  }
}

// iframe内でレンダリングされた場合にのみ発火させる
if (window !== window.parent) {
  // ...
  window.addEventListener('DOMContentLoaded', function () {
    // ...
    fakeAnchors()
  }, false)
}

なお、javascript を使わず、旧管理画面の view の各aタグを手で全て書き換える方が素直ですが、そうしなかった理由は、数が多いのと、暫くの間旧管理画面にダイレクトにアクセスできるパスは残しておきたかったためです。管理画面だから許される力技…です。

ページ内リンク問題

<a href=”#foo”>foo</a> のようなリンクです。iframe のオプションで scrolling=”no” している、また href をすげ替えた都合でスクロールしてくれないので、このようなリンクがクリックされた場合は、子から親に要素のポジションを計算して親側でスクロールさせるようにしました。詳細はサンプルコードを…といいたいところですがこの部分サンプル書けてないです :pray:

なお、production のコードではこの部分も window.postMessage() で 親にスクロール位置を通知させました。

ヘッダ・サイドバー消し

新管理画面の吸収されてしまった旧管理画面。もう旧管理画面のヘッダやサイドバーメニューは不要なので消します。旧管理画面側で DOMContentLoaded のタイミングで 追加の css ファイルを入れて、消し込むことにしました。

子側

const applyOpsCss = function () {
  const style = document.createElement('link')
  style.rel = 'stylesheet'
  style.href = '/css/additional.css'
  document.getElementsByTagName('head')[0].appendChild(style)
}


// iframe経由でのみ発火させる
if (window !== window.parent) {  
  applyOpsCss()
  window.addEventListener('DOMContentLoaded', function () {
    postMessage('PageDOMContentLoaded', {})
  }
}

  • iframe内でレンダリングされた場合に限り additional.css を適用する。additional.css 内では消したい要素に display: none; を適用している
  • DOMが読み込まれたら親に通知(次を参照)

親側

const messageHandlers = {
  // ...
  PageDOMContentLoaded: (_data) => { window.document.getElementById('proxy-iframe').style.visibility = 'visible' },
  // ...
}
  • スタイルを当てるまでの非常に短い間はヘッダ等が見えてしまうので画面がチラつく。これを防ぐために ngCloak 的なアプローチ、すなわち、iframe に `visibility : hidden;` で予め非表示にしておいて、追加のスタイルが適用されたら PageDOMContentLoaded メッセージを送信しiframe のdisplay visibility を `visible` に変更する

CORS でなければ親側だけで iframe 内の load を検知できそうな気はするのですが、CORS だったのでこのようにしました。

メニューのマージ

このタイミングでメニューバーを整理しました。新・旧それぞれのメニューバーにあった項目を整理し、新管理画面のメニューバーにマージしました。格段に見やすくなってこちらは評判です。

まとめと所感

iframe を使って複数の管理画面サイトをあたかも1つの統一されたサイトとして見せるパターンをまとめました。特に CORS 環境おいては window.postMessage() API を利用することで様々な課題を解決することができました。

この方式で本番運用して4ヶ月ほど立ちますが、大きなトラブルなく稼働できています。管理画面という特性上そのあたりは柔軟に対応できているのと、対応ブラウザを Chrome 1本に割り切ったので、導入後のメンテ工数は今のところほぼなく上手く動いてます。

本番の切り替えについては、旧画面と内容は変わらないので、導入調整コストがほとんどかからず、また利用者=オペレーターさん達の心理的負荷や学習コストも低く抑えることができました。これは本アプローチの最大のメリットではないかとおもいます。

ちなみに、このアイデアを思いついた翌週が運良く Hack It Day だったので、1日つかってプロトタイプを作って、どのあたりに技術課題があるか、工数感などつかむことができたのが良かったとおもいます。 * Hack-It Dayは月に一度、ラクスルのエンジニアが自由に開発することができる日)

さて、長くなりましたが最後までお読み頂きありがとうございます!!

ラクスルでは、絶賛エンジニア募集中です。
「仕組みを変えれば世界はもっとよくなる」
世界が変わっていく瞬間を一緒に体験したいエンジニアの方、お待ちしています☆

RubyKaigi 2017 in 広島!!!

RubyKaigi 2017 in 広島、昨日から3日間の日程で広島国際会議場で開催されています! 直前に台風の通過で天気が危ぶまれましたが、蓋を開けてみたら3日間快晴! 心地よい秋晴れです。

ラクスルもスポンサーとしてブースを出展中。今年も世界各国から、Ruby開発者やRubyを取り入れている企業の方など国際色豊かな雰囲気でカンファレンスは執り行われています。今年のラクスルブースへの最初のお客様はカナダの開発者の方で、弊社エンジニアの吉岡とともに最初から英語で企業説明したりと、盛り上がってます!

今年もカンファレンス参加者の方からお陰様で「ラクスル使ってます!」「最近入稿の仕組み便利になりましたね!(スピードチェック入稿)」などと嬉しいコメントいただきました。開発者としては身の引き締まる思い・・・。

RubyKaigiはコアな開発者が集まる会議とあって、最前線の情報を収集できる貴重な場とあってエンジニアメンツとしても貴重な時間です。ラクスル、ハコベルではRuby/Railsを用いて各種APIやWebシステムを開発しており、参加したエンジニアはブース応援傍ら気になるトークセッションに聞き入ってます。印刷のラクスルでどういうことにRuby使ってる?… とご興味のある方は是非お声がけください。

P.S. 今年も弊社技術顧問のまつもとゆきひろ先生にお立ち寄りいただきました。お忙しいなかありがとうございます!