EVOKEを支える大人数同時参加型クイズシステム開発前編

2017.12.18

アプリボットには独自の社内文化がたくさんあり、特に、半期に一度開催される「アプリボット総会」は全スタッフが参加する大規模なイベントです。今回からは各プロジェクトのプロデューサーによるプレゼンなどを行う新しい会として生まれ変わり、「EVOKE」と名付けられました。

EVOKEでは1部2部にプレゼンや表彰などが行われ、3部では新卒主導で労いを込めた打ち上げイベントを行います。

今回は、2017年10月に行われたEVOKE3部の内容および、そこで使用した技術を紹介します。

前半のこの記事では、開発したシステムの概要や開発手法などについて紹介をします。

概要

今回の3部で開発したコンテンツは、アプリボットの社員250人以上が同時に参加できる大規模なクイズシステムです。参加する社員は自身のスマートフォン端末から回答を送信し、クイズの正誤によってランクが変動していくという内容になっています。

採用技術

開発では、主に以下の技術を取り入れました。

（左上から順に、Javascript、Node.js、npm、Express、JSON Web Tokens、HTML5、Webpack、Sass(SCSS)、React.js、Vue.js、Unity）

前提として、開発期間が少なく、開発に関われる人数は複数人いるという状況だったので、各開発メンバーの得意な技術を生かし開発速度をあげつつ、常時このプロジェクトにコミットできるわけではないので、なるべく多くのメンバーがわかる言語を採用し作業の分担ができる状況にしました。

それ以外の主要な選定理由などは、開発セクションごとに説明していきます。

それでは、まずはバックエンドです。

バックエンド

サーバーにはnode.js + express、リアルタイム通信にはロングポーリング、データベースにはRealmを導入しました。

またパッケージ管理にnpm、バンドラーにwebpackを導入し、全員が一定の簡単な手順でビルド、起動ができるようにREADMEを整えました。

また、サーバー・クライアント間の通信部分の結合は分担すると非常に非効率的なため、フロントの開発ではメソッド呼び出しをするだけでサーバーから必要なデータが取得できるようなメソッドを用意しました。

技術選定

重視した点として、全体としては多くの人が馴染みの深い技術を採用しメンテナンス性をあげ、要件を満たした上で実装がなるべく楽な方法をとり、各開発者の観点では各々使いたい技術を採用できる状況が理想と考えていました。

webサーバー

node.js + expressはjavascriptではデファクトスタンダードと言っても過言ではないほど有名で、ドキュメントもサンプルも豊富なため今回の目的に最適でした。最近ではkoaというwebフレームワークも出てきていますが、まだドキュメントが少なく、そのようなライブラリはある程度環境が整うまでは予想もしないところで無駄に時間を取られる可能性が高く、設計や性能が優秀でも時間的な制約が大きい開発には不向きです。

双方向リアルタイム通信

サーバーからクライアントに対してイベント通知を送るという特殊な要件を満たすために、何らかの双方向リアルタイム通信を行う必要がありました。

双方向リアルタイム通信ではWebSocketが有名で、node.js向けにもsocket.ioというライブラリが出ていますが、RestAPIを使ったロングポーリングほど実装が簡単ではない上に、通知が必要なAPIが大きく増える見込みがなかったため、採用を見送り、ロングポーリングで実装を進めることにしました。

イベント通知は、本番にサーバーからクライアントに対して運営側で行う想定だったため、技術的知識がなくても簡単に進行できるように管理画面を作成しました。管理画面に関しては他にもいくつかの役割をもたせたので、後ほど解説します。

データベース

javascriptのようなオブジェクト指向言語と相性がいい、Realmというオブジェクトデータベースを採用しました。Schemaというデータの形式を定義し、データベースへの追加や取得、削除などの操作はその形式に基づいてjavascript向けのクライアントで行うので文字列でデータベースを操作するSQLと比較すると安全で、バグも起こりにくく、メンテナンス性も高いです。javascript向けに似たようなクライアントが存在するものでRedisもありますが、Realmほどデータの形式に関して厳密ではなく、高度な速度要件もないので、直感的に扱いやすいRealmを採用しました。

パッケージ管理

node.jsをインストールするとnpm（node package manager）も使えるようになります。最近だとパッケージ管理はyarnが有名で、並列処理によりnpmよりも高速ですが、機能的にはnpmで完結できるので、手順が増えることと、大して重いプロジェクトではない、かつ長期にわたって複数人が入れ替わり運用するプロジェクトではないので速度要件はそこまで重要ではなく、npmを選択しました。