CLOSE

Nuxt.jsとGraphQLから見えたWeb開発の未来(全1記事)

Nuxt.js+GraphQLを導入してみて感じた、フロントエンドエンジニアのこれから

2018年4月21日、株式会社サイバーエージェントが主催するイベント「Battle Conference U30」が開催されました。30歳以下のエンジニアによる30歳以下のエンジニアのための技術カンファレンスである本イベントには、さまざまな領域で活躍する若手が登壇。企業の枠を超えて、自身の技術・事業・キャリアに関する知見を発表しました。「Nuxt.jsとGraphQLから見えたWeb開発の未来」に登壇したのは、株式会社スマートドライブの大木尊紀氏。Nuxt.jsとGraphQLを開発に用いるメリットと、今後のフロントエンドエンジニアの価値について語りました。

Nuxt.jsとGraphQLに見る、Web開発の未来

大木尊紀氏(以下、大木):よろしくお願いします。「Nuxt.jsとGraphQLから見えたWeb開発の未来」とけっこう大層なこと言ってますけど、最後までお聞きください。

大木尊紀といいます。株式会社スマートドライブでフロントエンドのエンジニアをしています。

最近、Nuxt.jsとReactやっていたのと、Polymer Japanの中の人でドキュメントの翻訳とかをしています。来週の月曜日にWeb Componentsのイベントがメルカリさんであるので、ぜひ興味ある方はいらしてください(注:すでにイベントは終了)。

あと技術書典ではWebフォントの本とHyperappの本とWeb Componentの本を頒布するので、興味のある方はぜひいらしてください。

自己紹介はこれぐらいで、今日は弊社が4月に新しくリリースしたサービスの話をします。ちょっといろいろ出てきてますが、コードはほとんどありません。

「SmartDrive Cars」というサービスです。

どんなサービスかというと、一番大きく目指しているところは、安全運転をすると利益がドライバーに還元されるような社会の実現を目指すサービスです。

具体的には、カーリースとコネクテッドカー。弊社はB向けのサービスで、車にデバイスをつけて、そのデバイスから位置情報や加速度を吸い上げて可視化するというサービスをやっているのですが、それをカーリースとセット販売しています。

走行データの可視化や安全運転の診断など、まずは走行と安全運転の度合いからポイントを付与して、それをAmazonポイントなどに変えていけるような仕組みを提供しています。

技術構成ですが、フロントエンドはNuxt.jsを使っています。

バックエンドはRuby on Railsで、APIでGraphQLを使っています。フロントエンドはNuxt.jsのapollo-module使っています。GraphQLだけでなく、REST APIも一部使っているのですが、GraphQLも使っている。また、Herokuも使っていました。

開発体制は、フロントエンドは僕1人です。サーバサイドも1人、デザイナーも1人で、ディレクターも1人。デザイナーはほかのプロダクトも兼務しているので、実質0.5人ぐらいですね。あとはマークアップのエンジニアの方が外注で1人です。

Nuxt.jsを採用した理由

状況としては、SPAで作りたいという要望がありました。ユーザビリティとかそういうのを考えているというところです。リリース日はもう、ずらせないと。

あとは、先ほどカーリースを提供していると言いましたが、カーリースは、弊社ではなく協力会社が別にいまして、弊社はその会社の代理店になるかたちでサービスを運営しているので、その関係でけっこう仕様が変わる、出してほしい情報が変わるとか、こういう情報が出ていないとちょっとアウトとか、そうしたことがありました。

それにともなってデザインはFIXされないし、リソースが足りないのでマークアップは外部の方にお願いするし、実装期間は約1ヶ月半でした。

お気づきかと思うのですが、「リソース足りねえよな」というのがありまして、「フロントエンドの技術とか技術選定とかどうしよう?」というのを常々言っていたのですが、そこで出てきたのがNuxt.jsです。

Nuxt.jsってみなさんご存じですか? 最近有名になってきた。僕が使い始めた時はRCの1.00とかだったんですけど、今は1.……いくつだ? 出てるんですね。Nuxt 2がもうそろそろ出るんじゃないかと思います。

これはなにかというと、ユニバーサルVue.jsアプリケーションというやつで、ここらへんのサーバサイドレンダリングを含んだライブラリ群をまるっとまとめていい感じにしてくれるやつです。

メリットです。一番よかったのは、やっぱり開発スピードが速い。これもうすごく速いですね。全部やってくれます。webpackの設定もやってくれるし、ルーティングの設定もStoreの設定も全部やってくれてうれしい。Vue.jsなのであとはHTML・CSSをそのまま使えるし、ディレクトリ構成もある程度決まっているので悩む部分が少ないです。

「ライブラリどれ使おう?」みたいこともある程度決まっていて、nuxt-communityというコミュニティがあって、そこでNuxt用のモジュールもいくつか開発されています。それを使うとかなり便利にできました。

一番よかったのは、コアの部分に集中できたことです。webpackの設定など、煩雑な部分に時間をかけずにコアな部分、デザインの再現やアニメーション、基盤の設計などに時間を使えたのがすごくよかったです。

注意しなければいけないのは、やっぱりすごくブラックボックスなので、中でなにをやっているのかはきちんと知っておくことが大事です。とくに小さいライブラリではないので、エラーが出たときやバグったときにけっこう困ります。ですので、中身を知っておくことは大事です。

また、GraphQLを使ってました。GraphQLはクエリ言語です。エンドポイントが1つというのがREST APIと大きく違うところですね。

導入してよかったこと

今回導入を決めた理由ですが、先ほど言ったように、デザインは決まらないし仕様は変更いっぱいあるしで、フロントエンドとサーバサイドの開発をなるべく離していたい。ルーティングやUIに左右されずにでサーバサイドの開発がしたいということでGraphQLを取り入れました。

あとは、変更に耐えられる実装にしたいということ。僕はサーバサイドの人間ではないのでよくわかっていませんが、サーバサイドの人曰く導入コスト2日ぐらいということなので、「そんなに重くなかったんじゃない?」という話をしていました。必要なデータを1回のリクエストで全部持ってこれるようになるので、非常に便利でした。これは結果としてサーバとフロントが疎結合になったかな、というやつですね。

不必要なデータを取得しないので、返ってくるデータがすごく見やすくてシンプルです。明示的にフロントからこういうデータが欲しいですって言って取ってきているので、自分が今なにをリクエストして、なにが返ってきているのかというのがすごくわかりやすいです。

というのと、欲しいデータが変わったら、サーバの実装を変える必要はなくて、フロントエンド側でクエリを変更すればOKなので、それもいい点でした。あと、サーバサイドでフィルタリングできるのはよかったですね。

Storeがいらないのがすごくよかったです。そもそもStoreがいるのは複数のAPIがあって、そこをリクエスト結果をStoreでまとめてViewに表示しているのがけっこう多いと思うんです。

ですが、GraphQLはエンドポイント1個しかないので、Storeにデータをためる必要がないので、結果としてStoreがいらなくなるので、まぁよかったです。

GraphQLとREST APIは一緒に使えます。

「Vue.js触れます」は価値ではなくなる

最後に、こうしたフレームワークの登場でフロントエンドの敷居がすごく下がっていることを感じました。一昔前は、webpackの設定ができないとフロントエンドの開発ができないという風潮があったと思うのですが、こうしたものを使えば使えばすぐに誰でも動くものを作れるようになって、本当に数行のコマンドで作れるようになります。

なので、よりコアな部分で価値を発揮できる・していかなければいけない環境になってきたかなと。設計、機能開発、アニメーション、パフォーマンスです。

今までは「Vue.js触れます」「React触れます」で価値を作れたけど、これからはそうもいかなくなってくるので、より専門性を高めていく必要があるんじゃないかなという肌感があります。あとは中がわかる人は強いです。

GraphQlも、先ほど言ったようにStoreがいらなくなるので、そうした複雑なところを排除することができて、サーバのデータとフロントのUIをより直結して開発を行うことができる。本質的な開発に注力できるようになるということもあります。

効率的になる代わりに、本質を問われる

まとめです。便利で効率的になっていって、面倒な部分・複雑な部分がなくなって本質的な部分に集中できるという流れが今来ているかなと思います。フロントエンドのエンジニアとして全部できるということも大切ですが、その中で自分がなにが得意なのか、もっと突き詰めていく必要が出てくるのではないかと感じました。

ありがとうございました。

(会場拍手)

司会者:大木さん、ありがとうございました。それでは質疑応答の時間に移りたいと思います。質問のある方はいらっしゃいますでしょうか?

質問者1:すいません。話を聞いててちょっと気になったのが、GraphQLのモデリングを行う部分があると思うんですけど、あれをどちらが、サーバの人が書いたのか、クライアントの人が書いたのか?

大木:書いたのはサーバの人です。

質問者1:サーバの人?

大木:はい。

質問者1:だから、クライアントの要求に応じて作ったというよりは、裏側はORMかなにかのモデルと1:1対応してるみたいな感じなんですか?

大木:そうですね。先にサーバ側のモデリングがFIXして、その持っているデータは変わらないけど、View側でどう見せるかというのが変わる状況だったので、サーバの人がGraphQLの中でぜんぶAPIを実装して、それをフロントの人が使うみたいな感じでしたね。

質問者1:ありがとうございます。

司会者:ありがとうございました。それでは時間になりますので、質疑応答のお時間はこれで終了とさせていただきます。あらためまして、大木さん、ありがとうございました。

(会場拍手)

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!