社内業務ツールをVue.js/Vuex/rxjs/RailsでSPAで作ってみた話

配送サービスハコベルの担当の蟻塚です。

ここ1ヶ月半ほど、社内業務ツールを1人でSPAでモリモリ開発していたので、その話を書かせていただきます。

筆者のバックグラウンド

サーバーサイドエンジニア。SPAはBackbone/Marionette, React/Reduxで3回ぐらい書いたことがある。CSSもアニメーションも書けないのでフロントエンドエンジニアからは程遠い。SSRとかも詳しくない。

業務ツールの概要

  • 毎日の業務に使うので、使いやすさは重要
  • ジオコーディング等の非同期処理が数100〜件発生する
  • 社内でのみ使うツールであり、使用者は少人数。
  • 一度運用が回るようになりさえすれば改修はほとんど発生しない(想定)。
  • SSRとかは100%不要

今回使ったもの

フロントエンド

バックエンド

フロントエンドの話

なぜVue.jsを使うことにしたのか

1年ほど前に、React/Reduxで業務ツールを作ったことがあるのですが、その時の思い出として、

  • 開発速度が全然でない
  • 非同期処理を少し書くだけで実装どうするか迷う
  • middlewareを調べるのが手間
  • 関数型のノリが馴染まない

上記のような超個人的感想を持ちました。なので今回は、Vue.jsでSPAを作ってみることにしました。HTMLにJS直書きしているような雑なツールを作る際にVue.jsを使っていて、こっちのが楽なんじゃね、って思ったのもあります。

Vuex

reduxの影響でglobalなstoreでstate管理しようと思ってvuexを導入しました。ですが結局のところ、

  • コンポーネントlocalなstateはコンポーネントで管理する
  • 複数コンポーネント間でデータをやり取りしたいときだけ、Vuexを使う

という形にしました。たとえば、以下のようなものはVuexで管理することにしました。

  • ログイン情報
  • グローバルなメッセージ表示(snackbar)
  • 通信ローディング表示

こういうルールにした理由は、

  • URLに対応するようなコンポーネント(ex. アイテムリスト、アイテム詳細ページ)が破棄された場合は、そのデータを破棄したい。globalなstoreにデータを保存している場合は、明示的に破棄処理を書く必要がある
  • vuex使うと単純に実装時間が増える。
  • vuex付属のデバッガーをそれほど使わない(自分は)
  • そもそもあんまりstate管理に困っていなかった

上記のような理由からです。作るものによっては有用だと思うのですが、今回はそれほどメリットを感じなかったのでlocal管理にしました。

HTTP Responseをhookしてグローバルなメッセージを出す

例えばHTTPのレスポンスコードが500だった場合、エラー表示を出したいケース等あると思います。今回はできるだけ楽したかったので、axiosにインターセプターを登録して、レスポンスコードが200じゃなかった場合はエラーメッセージを表示することにしました。

  function serverErrorInterceptor(error) {
    const { message } = error
    store.commit(types.SHOW_MSG, {
      message: message,
      level: 'error',
    })
    store.commit(types.HIDE_LOADING)
    return Promise.reject(error)
  }

  client.interceptors.response.use(serverErrorInterceptor)

こういった処理はVuexを使ったおかげでスッキリ書けた印象があります。

rxjs

100回非同期処理を行って、10回成功する毎にDBに保存するためにサーバーにリクエストを投げる、みたいなことをシンプルにやりたくてrxjsを使いました。

人を選ぶツールかつ、イニシャルの学習コストが高いので気軽に導入しない方が良いと思いますが、時と場合によってはとても便利に使えます。上記のような例を普通に書くととても汚くなりがちですが、rxjsを使うとスッキリ書けます。

var Rx = require('rxjs/Rx')

const geocode = (v) => {
  return new Promise(resolve => {
    setTimeout(() => {
      console.log('geocode:' + v)
      resolve(v)
    }, v * 500)
  })
}

const save = (v) => {
  console.log("save: " + v)
  return new Promise(resolve => {
    setTimeout(() => resolve(v), 100)
  })
}

Rx.Observable.from([1, 2, 3, 4, 5, 6])
  .mergeMap(v => Rx.Observable.fromPromise(geocode(v)))
  .bufferCount(3)
  .mergeMap(locations => save(locations))
  .subscribe(
    () => { /* next */ },
    () => { /* error */ },
    () => console.log('complete')
  )

# output
-> % node sample.js
geocode:1
geocode:2
geocode:3
save: 1,2,3
geocode:4
geocode:5
geocode:6
save: 4,5,6
complete

Vuetify

https://vuetifyjs.com

vuetifyは、Material Component Framework for Vue.js 2 だそうです。SPAだとbootstrapはちょっと勝手が悪いので、vuetifyを使ってみました。現状使ってみて、ほとんど困ることはなかったのですが、

  • まだまだ開発途中(バージョンすぐ上がる)
  • 難しくはないが、ハマった時にソース読むしかない

1年後どうなっているかは不明ですし、まだproductionで使うには早いかな、といった印象はあります。ただ、こういったcomponent frameworkを使って開発する未来は近いという印象を受けました。概要は上記のリンクみて頂くのが早いと思います。

バックエンドの話

webpackerはどうなのか?

webpackerを使う前は、リポジトリのtopに /front  ディレクトリを作ってwebpackでビルドして、アセットパイプライン配下に放り込むスタイルでやってました。

webpackerの良いところは、railsにインテグレーションされていることだけです。悪いところは、webpacker特有のフォルダ構成になることです。

使用感としては、webpackerは開発初日に導入して以降はあまりいじることはありませんでした。また導入自体も困りませんでした。app/javascript/packs というディレクトリ構成はなんか嫌だなって思いましたが、生産性には何の関係もありませんでした。

基本的に、webpackの薄いwrapperであり、辞めたくなったらいつでも辞めれるので、オレオレ構成のwebpack railsインテグレーションするよりは、そのまんま使えば良いんじゃないか、というのが私の見解です。JS書くだけに使う分には困らないと思います。

終わりに

react nativeに対抗して、weex 作ってたりと、Vue.jsの周りのエコシステムもだいぶ充実してきているという印象でした。Backbone/Require.jsでSPA作ってた時代に比べるとだいぶツールも成熟してきており、生産性という観点でも JS FrameworkとComponent Frameworkを使って開発する未来が来てもおかしくないという印象があります。

また、Reactとの比較という点では、Vue.jsもかなり影響を受けており(勝手な主観ですが)、お互い大きな差分は減ってきているように感じます。おそらく React/Reduxで開発できる人は、Vue/Vuexでもそれほど学習コスト無く開発できると思います。

個人的にはVue.jsは開発しやすいフレームワークなので、興味を持った方は試してみては如何でしょうか。

採用もやってます! ↓


ペアデザイン

ラクスルでデザインを担当している中村です。

ラクスルに入社してはや半年が経ちました。
ラクスルでは、ここ最近は主にUCD(ユーザー中心設計)などを取り入れたUX活動やUI設計・プロトタイピングなどをしています。

さて、今日は先日実践した「ペアデザイン」についてお話ししたいと思います。

続きを読む


京都オフィス立ち上げ秘話

4月ですね。

これをお読みの皆様の会社でも、新入社員が入ってこられたでしょうか。
ラクスルも無事2名の新卒を受け入れることが出来ました。
1名はエンジニアですので、ここに登場してくれる日も近いことでしょう。

前置きが長くなりましたが、早いもので入社してそろそろ1年になるエンジニアの渡邉です。
春ということで、今回はラクスルが新しく拠点として立ち上げた、京都オフィスについて
お話したいと思います。

まずはこちらを御覧ください。

京都事務所開設のお知らせ

続きを読む


エクストリーム・プログラミング(XP)を用いた開発

経緯

「複雑化する仕様、委託先との契約形態、稼働スケジュールやキャパシティーという課題を全部解消し、ついでに、雪や地震等で、委託先の変更を迫られてもすぐに対応できるシステムを作ってくれ」と言われて、一体どのようなソリューションにすれば、正しい課題解決ができるのか。そのような緊急度が高く、要件が極めてふわっとしている状態でプロジェクトが難航している中、CTOの泉に突拍子もなく「この課題は、この会社と一緒に共同で解決してみてくれないか?」と言われ、出会ったのがPIVOTALと、その会社が推奨するXPでした。

開始前:XPについて

書籍 エクストリームプログラミング などを読んで勉強しました。ただ、書籍の内容は理解できるのですが、本当にそうなのか?という疑問を抱きました。

  • 疑問1: ペアプロは生産性が下がるのではないか?
  • 疑問2: 将来を見越した設計よりシンプルな設計?

続きを読む


ラクスルでの開発スタイルについて

はじめに

ラクスルでサーバーサイドエンジニアをしている田中です。
印刷ECタスクフォース(以下ECTF)というチームでテックリーダーを名乗っています。

入社して1年ちょっとになりますが、その1年間でもオフィスが移転したりメンバーが増えたり組織体制が変わったり。。。と目まぐるしく状況が変化する中で、
エンジニアに焦点を当てるとドラスティックに変わった(んだろうなぁ)と感じるのが開発スタイルでした。

ちょうど新しい開発手法の導入期からジョインして色々なことを体験したので、そこを少しご紹介したいと思います。

続きを読む


Electronを使ってデスクトップアプリを開発しました

ハコベルの開発をしている吉岡です。

入社してからずっと印刷ECの開発をしていましたが、
今年の5月からハコベルチームに移って開発してます。

ハコベルはインターネットを使って簡単に荷物の配送を手配できる
運送のマッチングサービスです。
もっと詳しく知りたい人はこの辺とかをぜひ見てみてください。

ちなみに、先日「Ruby biz Grand prix 2016」でハコベルがグランプリを受賞しました。
興味のある方は是非こちらもご覧ください。
https://www.wantedly.com/companies/raksul/post_articles/46184

それでは開発の話へ。

続きを読む


Raksul Meetup#3 を開催しました -アプリ編(後編)-

9月上旬に行ったAWS移行・・・前編につづいて、後編では移行の直前から移行後までの詳しい流れと、そこで得た学びについてお伝えできればと思います。

移行時の準備

システムの移行は常に「何か問題が起きる」もの・・・事前に用意できるものは、なるべく事前に用意しておきたいものです。

今回準備したものの一例としては、移行当日までに「いつまでに」「誰が」「何を」やっておくべきかをリストにした事前作業チェックシート。これに沿って当日本当に移行できる状態にあるかを確認します。 続きを読む


Raksul Meetup#3 を開催しました -アプリ編(前編)-

ラクスルに入社してから今月でちょうど入社から1年経った新米エンジニアの泉です。
思い起こすと「一年色々あったなぁ」と感傷にふける今日この頃です。

さて、9月上旬に行ったAWS移行について、インフラチームの渡邉よりインフラ側のブログ記事がありましたが、今回はアプリ側がどのような準備を経て移行をしたかを説明します。

続きを読む


Raksul Meetup#3 を開催しました -インフラ編-

幼いころは外交官を目指していた意識高い系インフラエンジニアの渡邉です。

5月にラクスルに入社し、最初の大きなミッションであったAWSへの移行を9月頭に実施しました。その際に得た知見や工夫した・改善した部分を、同じようにレガシーシステムと戦っている皆様に共有すべくMeetupを開催させて頂きました。

そこでの発表内容をインフラ編・アプリ編と二回に渡りご紹介させていただきます。

raksul_meetup_01

続きを読む


ラクスルECサイトとInternet Explorerの関係

はじめに

ラクスルのフロントエンド周りを担当している野口です。

デザイナーとフロントエンドエンジニアが社内に0(正確には前にいたがしばらくいない期間があった)の状態から、ラクスルにジョインして早2年が経ちました。今ではデザイナー3名、フロントエンドエンジニア3名、サーバーサイドのエンジニアも約3倍近くになり、メンバーがほんと増えたなぁとしみじみ。

さて、今年の1月12日(米国時間)にIEのサポートポリシーが変更となりました。使用しているOSでサポートされる最新バージョンのIEだけが、技術サポートとセキュリティアップデートを受けられるということに。
※ Internet Explorer サポートポリシー変更の重要なお知らせ
https://www.microsoft.com/ja-jp/windows/lifecycle/iesupport/

変更から8ヶ月以上が経過しましたが、みなさんが作っているサイトを利用しているユーザーの環境に変化はありましたか?開発する上でも変化はあったでしょうか?

IEのサポートポリシー変更にともない、確実に変化があったはずです!弊社ラクスルが運営するネット印刷のECサイト(raksul.com)においても変化があり、「ラクスルECサイトとInternet Explorerの関係」と題して、変化や取り組んだことについて書いてみたいと思います。

続きを読む