GameWith Developer Blog

GameWith のエンジニア、デザイナーが技術について日々発信していきます。

TypeScript と aspida で型安全に Vue.js の開発をしている話 #GameWith #TechWith

はじめに

こんにちは! GameWith の kuromoka です!

今回のブログでは、GameWith のダッシュボードの開発に、aspida という API のリクエスト/レスポンスに型を付与するライブラリを導入した話を紹介したいと思います。

ダッシュボードのフロントエンド環境については、Vue.js + TypeScript を導入しています。以下の記事も合わせてご参考ください。

tech.gamewith.co.jp

課題

前述の通り、GameWith のダッシュボードは Vue.js + TypeScript を導入しています。これまで API にリクエストするときは axios を使って以下のように書いていました。

async getPostData(): Promise<any> {
  const response = await axios.get('/api/post');
  return response.data.post;
}
async postPostData(title: string, text: string): Promise<any> {
  const response = await axios.post('/api/post', {
    title: title,
    text: text
  });
  return response.data.post;
},

この書き方には、以下のような課題があります。

  • URL の文字列部分を typo しても TS のコンパイルは通ってしまうため、実行するまで間違いに気づくことができない
  • 関数名と API のリクエスト先が紐付いていないため、関数名からどこにリクエストしているか分かりづらく、また API の種類が増えていくと命名に悩む
  • レスポンスの型を any にしているため、型安全なコードでなくなっている

これらの解決方法として、今年の3月に行われた Roppongi.ts #1 のセッションの1つに aspida を利用している話があり、そこで初めて aspida を知りました。

ちょうど今回の課題を解決するのに、aspida が利用できそうだったので導入することにしました。

aspida とは

github.com

aspida を使うと、以下のようなことができるようになります。

  • API のリクエスト/レスポンスに型を付与できる
  • API のリクエストを文字列ではなく、プロパティ経由で行えるようになる

aspida を作成した方の記事もあるので、こちらもご覧ください。

qiita.com

使い方

プロジェクトのルートに aspida の設定ファイル aspida.config.js を作成して、以下のように設定します。今回は dashboard/apis 以下を aspida の定義ファイルを置くディレクトリに指定しています。

module.exports = {
  input: 'dashboard/apis'
};

aspida ではディレクトリ構造と定義ファイルの名前が、そのままAPIのリクエスト先になるイメージになります。

たとえば dashboard/apis/api/post/index.ts に以下のような定義ファイルを書いた場合、 api/post で GET リクエストを送信するための定義になります、

dashboard/apis/api/post/index.ts

export interface Methods {
  get: {
    query?: {
      page: number;
    };
  
    resBody: {
      posts: {
        id: number;
        title: string;
        text: string;
      }[];
    };
  };
}

aspida では API 定義をした後に、以下のコマンドでビルドする必要があります。

$ aspida --build

ビルドすると$api.tsというファイルが生成され、今回の場合 dashboard/apis/$api.ts にファイルが生成されます。

あとは以下のようなコードで axios で aspida を使って、API リクエストを送ることができます。

import axios from 'axios';
import aspida from '@aspida/axios';
import api from './apis/$api';

const client = api(aspida(axios));

(async() => {
  const response = await client.api.post.$get({
    query: {
      page: 1
    }
  });
  response.posts.forEach(post => {
    console.log(post.id);
    console.log(post.title);
    console.log(post.text);
  });
})();

VSCode で確認すると、リクエスト/レスポンスの部分に、先ほど定義した型が付与されていることが確認できます。 f:id:kuromoka16:20200928183757p:plain

そのためプロパティ名が間違っていたりすると、エラーになるため間違いに気づくことができます。 f:id:kuromoka16:20200928185438p:plain

また URL にリクエストパラメーターが含まれる API の場合は、ファイル名に_から始まる変数名と@の後に型を指定します。型は numberstring の2つが指定できるようです。

以下は ID を指定する API で、api/post/1のような URL に DELETE でリクエストをするAPIになります。

dashboard/apis/api/post/_id@number.ts

export interface Methods {
  delete: {
    resBody: {
      status: 'failed' | 'success';
    };
  };
}

これを使う場合は以下のようになります(リクエスト部分のみ)。

(async() => {
  const response = await client.api.post._id(1).$delete();
  if (response.status === 'success') {
    console.log('success!');
  }
})();

IDは number のため、たとえば _id() の部分で string を送ろうとすると、エラーになります。 f:id:kuromoka16:20200928191130p:plain

テストコードの書き方

テストコードは Jest で書いています。aspida の部分のテストは、以下のように aspida のモックを作ってテストコードを書いています。

モックのデータ生成時に型補完を効かせるために、aspida から型情報を取得して利用しています(type PostTypeの部分)。

type PostType = ReturnType<typeof client.api.post.$get> extends Promise<infer T> ? T : never;
const mockPost = jest.spyOn(client.api.post, '$get');
const mockValue: PostType = {
  posts: [
    {
      id: 1,
      title: 'title 1',
      text: 'text 1',
    },
    {
      id: 2,
      title: 'title 2',
      text: 'text 2',
    },
  ]
};

// コンパイルを通すために any にしております・・・・・・
mockPost.mockReturnValue(mockValue as any);

// fetchPost 内で client.api.post.$get を実行している
const data = await fetchPost(1);

// ID = 1のデータをテスト
expect(data[0]).toEqual(mockValue.posts[0]);

今は aspida-mock というライブラリがあるらしく、これを利用することで今より楽にテストコードを書けそうなので、利用してみたいと思っています。

github.com

メリット/デメリット

apisda を使うことで、以下のようなメリットがあると感じました。

  • ディレクトリ構造がそのままリクエスト先になるため、分かりやすい
  • APIへのリクエストがプロパティ経由で書けるためコード補完が効き、またリクエスト/レスポンスともに型情報が補完されるので書き心地が良い
  • aspida は日本人の方が作成しているので、日本語のドキュメントがある

デメリットは GitHub のドキュメントは充実していますが、まだまだ利用例が少ないため、例えばテストコードを書くときなどに少し苦労しました。

終わりに

API 側とフロント側での型定義は連携が取れていないので、現在はそれぞれに型定義ファイルが存在しています。今後 Open API を使うなどして、二重管理になっている型定義を共通化していきたいと考えています。

またデメリットの部分でも書きましたが、aspida はまだ利用例が少ないと思っていますが、便利なのでもっと普及していってほしいと思ってます。

他のサービスでは今回のような場合にどのように管理しているか気になっているので、よければ Twitter でリプライなどいただけるとうれしいです!

Twitter

GameWithのDeveloper向けTwitterアカウントも開設しました。
ブログの更新情報などを発信するので良かったらフォロー宜しくお願いします!

twitter.com

VSCode Live Share がとても良かった話 #GameWith #TechWith

はじめに

こんにちは! リプレイスチームの @53able, @inosy22, @nog です!

今回は VSCode Live Share 使ってみたので感想など書いていきたいと思います!

使ってみたきっかけ

リプレイスチームでは、”開発で困ったらペアプロ(モブプロ)で解決する” という取り組みを行っています。

今までは Google Meet で画面を共有しながら、VSCode を表示して、Meet のチャットでコードを送ったりしてペアプロを行ってきました。

オンライン上でペアプロ(モブプロ)をしているときに、チャットでコードを送ったり、そのコードを口頭や文章で補足したりするのが全員がリモートだと特に非効率だったので利用してみました。

VSCode Live Share とは

docs.microsoft.com

ホストの VSCode のプロジェクトを共有して、リアルタイムで他のユーザーと共同で編集などができるツールです!

ホストの VSCode をリモートコントロールしている感覚に近いです。

できること

Share できるのは、プロジェクト内のファイル操作 or ターミナル操作ができます。

また、VSCode 内でチャットができます。

Participants でユーザーにチェックをつけるとそのユーザーの操作を追従するモードになり、カーソル位置や開いているファイルなどの操作を追従するようになります。

この追従の仕組は最初使い方がわからなかったのですが、共同編集をしているユーザーにチェックを付けて追従を開始することで、チェックしたユーザーの作業箇所にジャンプができ、並行して作業をしても迷子になることはなかったです!

ちょっと作業をして悩んだときに、他の人を今作業しているファイルに集まりやすくとても便利でした!

f:id:tiwu:20200821165209p:plain

導入手順

インストール

まずは plugin を インストールします。

marketplace.visualstudio.com

f:id:tiwu:20200821164950p:plain

アカウントの紐付け

Microsoft か Github アカウントでログインをします。

f:id:tiwu:20200821165028p:plain

Share 手順

URL を発行して共有することで Live Share ができます。

f:id:tiwu:20200821165122p:plain

実際に使ってみた

このブログを VSCode Live Share で書いてみました!

今までモブブログは google docs の共同編集を使っていました。

f:id:tiwu:20200821165307p:plain

良かった点

  • 状況により並行して開発を行えたり、柔軟にコミュニケーション取りながら開発ができるため、効率的に作業が行える
  • 口頭でファイルや行の指示するのではなく、追従の仕組みを使って自分が実際にファイルを開き共有ができるので、スムーズにコミュニケーションがとれる
  • 吹き出しの様なものでカーソルが表示されるので、誰が今どのファイルの何行目を修正しているか見やすい
  • ブラウザ上でも Live Share の共有ができるので、 VSCode をインストールしていない人でも共同作業ができる

難しかった点

  • ホストがエディタを再起動すると、作業が中断する
  • .gitignore に追記しているものは共有されず node_modules などが登録されていると、ゲスト側は node_modules が見えず補完が効かない
  • 同時に同じ箇所を修正していると、編集した箇所が消えたりして、操作の衝突があったりする
  • 共有されるのは VSCode なので、コード以外のブラウザの共有などのため Google Meet で画面共有は別途行った

まとめ

導入も簡単で、共有を受ける側も簡単にできるのでとても使いやすかったです!

以前のように、Meet で VSCode の画面を共有してペアプロをするより遥かに効率的でした!!!

ありがとう VSCode! ありがとう Live Share!

他のエディタにも同様な機能があると嬉しいな・・・!

Twitter

GameWithのDeveloper向けTwitterアカウントも開設しました。
もくもく会の告知やブログの更新情報などを発信するので良かったらフォロー宜しくお願いします!

twitter.com

GameWith メンバーのリモートワークデスク事情! #techwith #gamewith

はじめに

こんにちは! GameWith のエンジニアの tiwu です!

gamewith.co.jp

弊社は新型コロナウイルス感染症拡大に備えた在宅勤務(フルリモートワーク)を2020年3月30日から実施しています。

そこで、今回のブログは GameWith メンバーのデスクについて写真と一言コメントともに紹介していきたいと思います!

Tさん

f:id:tiwu:20200716173006j:plain

L字のテーブルを有効活用し、ウルトラワイドモニターを活かす匠のデスク。

Tさん

f:id:tiwu:20200716172932j:plain

モニター小さくて作業辛いので、モニターアームとディスプレイ注文中。

Kさん

f:id:tiwu:20200716172836j:plain

部屋の奥に横100cmのスペースがあったのでちょうど収まるように横100cmのデスクを設置。

電動昇降デスクを設置予定。

clas.style

Lさん

f:id:tiwu:20200716174332p:plain

大大大好きな彼女からもらったデスクがポイントです。

Tさん

f:id:tiwu:20200716175048j:plain

f:id:tiwu:20200716175111j:plain

ミクさん(とプラモ)。同じモニタでwindowsやswitchなどのゲームプレイできます。

Yさん

f:id:tiwu:20200716183303j:plain

最近デスク周りのライト設備を増やしました。

デスク裏にはLEDライト貼り付けて、その日の気分に合わせてムード変えたりしてます。

モニター裏にもライトライトを点けて置くことで、モニターの光と裏の影のコントラスト和らげてます。

Iさん

f:id:tiwu:20200720120848j:plain

ゲーミングPC系の機材環境に仕事用のMacを繋いでます。仕事モードとゲームモードを簡単に切り替えられるように頑張ってるので配線が汚い!

机全面のマウスパッドがかなり快適なので、マウスパッドは大きめがオススメです!

Oさん

f:id:tiwu:20200720160138j:plain

最後に

エンジニアやデザイナーに協力をお願いしたのですが皆さん個性的でそれぞれ最高のパフォーマンスが出るよう工夫されていますね!

Twitter

GameWith の Developer 向け Twitter アカウントを開設しました!

ブログの更新情報などを発信するので良かったらフォロー宜しくお願いします!

https://twitter.com/gamewith_devtwitter.com

エンジニアがオブジェクト指向 UI デザインに入門しています #GameWith #TechWith

こんにちは! エンジニアコミュニティでは、ごーと呼ばれている只野です。

tl;dr

今回は、弊社サービス開発エンジニア3名が オブジェクト指向UIデザイン(OOUI) という手法を学んでみて、所感を持ち寄りました。

オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 から、キャッチアップをさせていただいております。

OOUI を知る前後の考え方は、人によって違うところがあるだろうと想像し、このことをテーマに話したら、デザイン手法を学ぶモチベーションが今後も高まることを期待して進行していきます。

よかったらお聴きください。

出演者

  • エンジニアマネージャー: serima
  • iOSエンジニア: かつらやま
  • フロントエンドエンジニア: ごー

編集後記

OOUI は、我々がよく使う OS で既に実現されています。

ユーザーは、作業フローに支配されているのではく、フレキシブルな方法で操作を成し遂げられるデザインであることが大いに便利であることがわかります。

今回の収録に向けて、オブジェクト指向 UI デザインを学んでみて、使い勝手が良いデザインをイメージできるようになったと実感しています。

UI を構成している部品それぞれを直感的に操作できることが、便利で欠かせない要素であると心から感じますし、サービス開発においても OOUI の手法で今後アプローチしてみたいと思いました。

再現性が高いであろう OOUI の手法は、サービス開発に関わる組織の誰にでもそうですが、特にエンジニアにはかなり親和性があるのではないでしょうか。

オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 、お薦めです。

終わりに

GameWith の Developer 向け Twitter アカウントを開設しました。

技術やブログの更新情報などを発信するので良かったらフォロー宜しくお願いします!

https://twitter.com/gamewith_devtwitter.com

GameWith における CLB から ALB への移行 #GameWith #TechWith

はじめに

こんにちは!リプレイスチームの野口と @inosy22 です!

今回のブログは GameWith のロードバランサーを AWS の CLB から ALB に変更した背景や変更手順、詰まったところや解決方法について書いていきたいと思います!

リプレイスに関してはこちらの記事で紹介しています!

tech.gamewith.co.jp

ALB(Application Load Balancer)とは

docs.aws.amazon.com

サービス概要

ALB は、アプリケーションレイヤー (L7) でルーティング決定を行い、パスベースのルーティングをサポートしている高機能なロードバランサーです。

メリット

  • パスベースルーティング
    • URLのパスによって Lambda や EC2, ECS などに振り分けることができます!
    • 例:/api の時にAPIサーバー、/app の時にアプリケーションサーバーに振り分ける
  • リスナールール
    • URL のパス以外にも、IP や UserAgent で振り分けることもできます!
  • AWS WAF (Web Application Firewall) が利用できます!

なぜ CLB から ALB に変更をしたのか

主な理由はパスベースルーティングでリプレイスしたサービスに段階的に振り分けることをしたかったからです。

GameWIthが利用していた CLB では上記のような柔軟な振り分けが難しかったので、ALB に変更することにしました。

それ以外にも ALB だけでメンテナンス画面を表示する対応が完結したり、リスナールールで IP 制限など、メリットが多かった為です。

移行方法

1. ALB を作成する

ALB は ALB の作成画面で簡単に作れます。

しかし、CLB から ALB に移行する場合、CLB の画面から移行ウィザード経由で作る方法があります。

docs.aws.amazon.com

GameWith は独自のスケーリングシステムを構築しているので、CLB の移行機能ではなく、ALB 作成画面から ALB を作りました。

2. 独自のスケーリングシステムの改修

GameWith は EC2 の台数を独自のスケーリングシステムによって増減させています。

www.slideshare.net

このシステムを ALB に対応させるため改修を行いました。

詰まったところ

独自のスケーリングシステムは、ALB のリクエスト数によってスケールの基準を変更しています。(例:20万アクセスだったら20台)

CLB の時と同様に実装をしたところ、リクエスト数の取得を安定して行えませんでした(例:たまに取得できなかったり、取得できても0アクセスだったりなど)

CLB の場合は1〜2分前のリクエスト数であっても安定的に取得ができていたのですが、ALB ではそれがうまく動きませんでした。

そこで、リクエスト取得の時間を5〜6分前に変更してみたところ安定して値が取得できるようになりました。

いろいろと調査をしているなかで似たような問題を Google フォーラムで取り上げられているのを発見でき、解決の糸口となりました。

3. 移行前に ALB の暖気申請をする

暖気申請とは、予めスパイクが来そうな時間を AWS に伝え、CLB から ALB の切り替えによって瞬間的に増える大量の接続をさばけるように ALB のキャパシティを事前に上げておいてもらう申請のことです。(AWS サポートプランのビジネス・エンタープライズに入っているのが条件です)

今回の暖気申請の理由としては、GameWith はアクセス数が多いサービスなので、切り替えの瞬間などで落ちないように申請をしました。

実は暖気申請の存在を知らず、移行リリースギリギリに知りました。

知った当日に申請をしましたが、リリース日には間に合わず、リリースの予定を後ろにずらしました。

詰まったところ

ALB の暖気申請をする場合はマルチ AZ で配置をする必要があります。

GameWith の場合はシングル AZ だったため、暖気申請のためにマルチ AZ 配置をしました。

終わりに

これからサービスが成長する際に、パスベースルーティングが使えるようになりマイクロサービス化がしやすくなりました!

独自スケーリングシステムがブラックボックス化していたので、リファクタリングしバージョンアップができたのでよかったです!

暖気申請は忘れずに!(2回目)

GameWithのDeveloper向けTwitterアカウントも開設しました。

ブログの更新情報などを発信するので良かったらフォローよろしくお願いいたします!

https://twitter.com/gamewith_devtwitter.com

エンジニアの教養について談義しました #GameWith #TechWith

こんにちは! エンジニアコミュニティでは、ごーと呼ばれている只野です。

tl;dr

今回は、弊社サービス開発エンジニア3名が 教養 に関して、これまでの開発キャリアでどんな視点を持つようになったのかを意見交換をしました。 雑談するノリでゆるい掛け合いをしています。 よかったらお聴きください。

出演者

  • エンジニアマネージャー: serima
  • シニアエンジニア: のぐち
  • フロントエンドエンジニア: ごー

編集後記

なぜ、このような収録を公開してみようかというと、上司の serima とは、30分〜1時間の 1on1 をしていて、お互いにいい歳なので内容は話題が多彩な雑談(笑)になっていました。

機密事項以外であれば公開してみると、GameWith のサービスは、どんなエンジニアが開発にあたっているのかを伝えることが出来て、おもしろいんじゃないかと提案してみました。

初回なので、多少お聴き苦しいことは否めないですが、今後は更にキャラが立った話をお届けできたらと思います。

終わりに

GameWithのDeveloper向けTwitterアカウントを開設しました。

技術やブログの更新情報などを発信するので良かったらフォロー宜しくお願いします!

https://twitter.com/gamewith_devtwitter.com

ダッシュボードの新機能開発にVue.jsを導入した背景と苦労したこと #GameWith #TechWith

こんにちは!サーバサイドエンジニアのkuromokaです!

こちらの記事でもあったように、GameWithのリプレイス開発ではVue.jsを使っています。 tech.gamewith.co.jp

今回はリプレイスではなく、GameWithの社員の方が使っているダッシュボードの新機能開発に、Vue.jsを導入した背景と苦労したことについて、お話します。

Vue.jsを導入した背景

GameWithのダッシュボードは社員の方しか見れない画面で、フロント側は次のような技術が使われています。

  • Bootstrap v2.0.3
  • jQuery v1.8.3

それぞれのリリース日を調べてみたら、Bootstrap v2.0.3は2012年の4月*1、jQuery v1.8.3は2012年の11月*2のようです。

2020年の今となってはかなり昔のバージョンを使っているのですが、裏側の画面のためにフロント側で凝った画面にする機会があまりなく、苦労さは感じつつ開発はしていました。

ただダッシュボードが使い辛いことでの作業効率が下がっているという話はたびたび聞いていて、今回もそういった作業効率を改善するための新機能開発でした。

今回の新機能はかなり根本的な改善を行うための機能だったため、フロントの改修も大幅に必要な見込みになりました。

開発チームでも相談して、この開発を今のフロント環境でやるのはちょっと辛いなということになりました。 あとはダッシュボードなので比較的新しい技術を取り入れやすいというのもありました。

そういった経緯で、今回はVue.jsを採用することにしました。具体的には次のような技術を使いました。

  • Vue.js v2.6.11
  • Composition API
    • Vue.js3系に備えて採用。v2系のため@vue/composition-api を導入
  • BootstrapVue
    • Bootstrap v4ベースのコンポーネントを、Vueコンポーネントとしてコーディングするため
  • Vue CLI
  • TypeScript
  • Jest
  • Go(バックエンドAPI)
    • Vue.jsからは基本的にGoのAPI経由で、データの取得や更新を行う

Vue.jsの導入で苦労したこと

今回の新機能開発に関しては、開発環境が整ってからはVue.jsの恩恵も受けながらスムーズに開発できたので、新しい環境にして良かったと思っています。*3

ただVue.jsの導入までが、既存プロジェクトへ導入するような事例があまり見つからないのと、私自身もそこまでVue.jsに詳しいわけではなかったので結構苦労しました。

細かいところを含めればもっと紹介したいのですが長くなってしまうので、今回は「既存プロジェクトへのVue.jsの導入で苦労したこと」について、3点紹介します。

1. Vue.jsのインストールからビルドまで

Vue.js公式ドキュメントには、CDN・NPM・Vue CLIでのインストールが紹介されています。最初は一番手軽なCDNにしようとも思ったのですが、今後規模が大きくなることやビルド設定が最初から入っていることもあり「Vue CLI」でインストールをしました。 jp.vuejs.org

ダッシュボードの画面はPHPで動いています。PHPのプロジェクト内に、Vue CLIで「frontend」プロジェクトを作りました。

$ cd ${DASHBOARD_APP_PATH}
$ vue create frontend


Vue CLI v4.1.1
? Please pick a preset: Manually select features
? Check the features needed for your project: Babel, TS, Linter, Unit
? Use class-style component syntax? Yes
? Use Babel alongside TypeScript (required for modern mode, auto-detected polyfills, transpiling JSX)? Yes
? Pick a linter / formatter config: Basic
? Pick additional lint features: (Press <space> to select, <a> to toggle all, <i> to invert selection)Lint on save
? Pick a unit testing solution: Jest
? Where do you prefer placing config for Babel, ESLint, etc.? In dedicated config files
? Save this as a preset for future projects? No

Vue CLIはビルド設定が最初から入っているため、$ npm run build するだけで、ビルド結果が出力されるのはすごく楽でした。

ただそのままだとVue CLIで作った、「frontend」プロジェクト内にビルド結果が出力されます。公開フォルダにはしていないため、PHPから参照することができません。

そのためアセットの公開フォルダに対して、ビルド結果が出力されるように、vue.config.jsファイル*4を作って設定を調整しました。

具体的には、次のようにoutputDirassetsDir を調整しました(いろいろな事情がありVue CLIのプロジェクトが深くなっているので、こんな相対パスになっています)。

module.exports = {  
  outputDir: '../../../../../public/', 
  assetsDir: './assets/frontend/',
}

最後に公開フォルダに出力するようにしたビルドファイルを、PHPから読み込むようにしました。

<script src="/assets/frontend/js/app.js"></script>

2. カレントパスによるコンポーネントの切り替え

見ているページのカレントパスでVueコンポーネントを切り替えるために、「vue-router」を使いました。 router.vuejs.org

初期化時に追加していなかったので$ vue add routerで後から追加しました。このコマンドでvue-routerのインストールとサンプル用のルーティング設定まで一通りやってくれます。

Vue CLIはデフォルト設定だと #appの要素にApp.vueがマウントされる設定になっています。今回App.vue<router-view/>を追加して、この部分をvue-routerで切り替えるようにしました。

<template>
  <div id="app">
    <router-view/>
  </div>
</template>

PHPからは、Vueコンポーネントを表示したい箇所に#appを書きます。あとはvue-routerのルーティング設定を調整すれば、カレントパスによって#appの部分が切り替わるようになります。

<div id="wrap">
  <div id="app"></div>
</div>

3. ホットリロードで開発する

今回一番苦労した点です。

Vue CLIには最初からホットリロードが有効な開発サーバが$ npm run serveで起動できるようになっています。
ただ今回は「PHPの一部分をVue.jsにした環境で、Vue.jsの部分だけホットリロード」するような挙動にしたかったので、そのままでは開発サーバが使えませんでした。

そのためしばらくは$ npm run buildで毎回ビルドして確認していましたが面倒で開発効率が悪いので、なんとかホットリロードを使えないか調べてみました。

調べていく中で、vue.config.jsdevServer.proxyという、設定が使えそうなことが分かりました。この設定を使うと開発サーバの特定パスへリクエストがあったときに、別サーバにプロキシさせてリクエストすることができるようになります。 cli.vuejs.org

一部省略していますが、実際に設定したvue.config.jsは次のような感じです。http://php-local-server/はPHPのローカル開発サーバです。/なので全てのリクエストをPHPにプロキシさせています。

module.exports = {  
  host: '0.0.0.0', 
  port: 9000,   
  proxy: {   
    '/': {  
      target: 'http://php-local-server/',  
      secure: false,   
      cookieDomainRewrite: 'localhost',        
    },
}

PHPではサーバ変数の$_SERVER['HTTP_X_FORWARDED_HOST']でプロキシ時のホスト名を取ることができます。
この値を見てlocalhost:9000の場合にhttp://localhost:9000からのパスで、ビルドファイルを読み込むようにしました。

<script src="http://localhost:9000/assets/frontend/js/app.js"></script>

ここまで設定すれば、

  • $ npm run serveで、Vue CLIの開発サーバを起動
  • http://localhost:9000/vue-js-pathで、Vue.jsを使っているページを見る
    (PHPのhttp://php-local-server/vue-js-pathがプロキシ経由で表示される)
  • Vueコンポーネントを更新するとビルドが走って、Vue.jsの部分だけ自動でリロードされる

という感じで開発ができるようになって毎回のビルドが不要になりました!これで当初目指した「PHPの一部分をVue.jsにした環境で、Vue.jsの部分だけホットリロード」を実現することができました。

まとめ

今回はダッシュボードの新機能開発に伴う、「Vue.jsを導入した背景」と「Vue.jsの導入で苦労したこと」をお伝えしました。

記事で紹介した「frontend」プロジェクトは、今は「GameWithのリプレイスについて vol.2 ~Web Components を Vue で書いたら最高だった編~ #GameWith #TechWith - GameWith Developer Blog」で紹介した「GameWithDesignSystem」のように別システム化をして、PHPのプロジェクトから独立して開発できる環境に改善をしています。

今回の内容が同じような悩みの人に対して、少しでも参考になる情報だったら嬉しいです!

終わりに

GameWithのDeveloper向けTwitterアカウントを開設しました。

技術やブログの更新情報などを発信するので良かったらフォロー宜しくお願いします!

https://twitter.com/gamewith_devtwitter.com

*1:https://blog.getbootstrap.com/2012/04/24/bootstrap-2-0-3-released/

*2:https://blog.jquery.com/2012/11/13/jquery-1-8-3-released/

*3:Composition APIだけは苦労したのですが、RFCを見たりGitHubでコード検索をしたりして、書き方に慣れていくようにしました

*4:https://cli.vuejs.org/config/ 今回このファイルを触る機会が多かったので、とても参考になったページです