2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
Nuxt.jsとGraphQLから見えたWeb開発の未来(全1記事)
リンクをコピー
記事をブックマーク
大木尊紀氏(以下、大木):よろしくお願いします。「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人です。
状況としては、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は一緒に使えます。
最後に、こうしたフレームワークの登場でフロントエンドの敷居がすごく下がっていることを感じました。一昔前は、webpackの設定ができないとフロントエンドの開発ができないという風潮があったと思うのですが、こうしたものを使えば使えばすぐに誰でも動くものを作れるようになって、本当に数行のコマンドで作れるようになります。
なので、よりコアな部分で価値を発揮できる・していかなければいけない環境になってきたかなと。設計、機能開発、アニメーション、パフォーマンスです。
今までは「Vue.js触れます」「React触れます」で価値を作れたけど、これからはそうもいかなくなってくるので、より専門性を高めていく必要があるんじゃないかなという肌感があります。あとは中がわかる人は強いです。
GraphQlも、先ほど言ったようにStoreがいらなくなるので、そうした複雑なところを排除することができて、サーバのデータとフロントのUIをより直結して開発を行うことができる。本質的な開発に注力できるようになるということもあります。
まとめです。便利で効率的になっていって、面倒な部分・複雑な部分がなくなって本質的な部分に集中できるという流れが今来ているかなと思います。フロントエンドのエンジニアとして全部できるということも大切ですが、その中で自分がなにが得意なのか、もっと突き詰めていく必要が出てくるのではないかと感じました。
ありがとうございました。
(会場拍手)
司会者:大木さん、ありがとうございました。それでは質疑応答の時間に移りたいと思います。質問のある方はいらっしゃいますでしょうか?
質問者1:すいません。話を聞いててちょっと気になったのが、GraphQLのモデリングを行う部分があると思うんですけど、あれをどちらが、サーバの人が書いたのか、クライアントの人が書いたのか?
大木:書いたのはサーバの人です。
質問者1:サーバの人?
大木:はい。
質問者1:だから、クライアントの要求に応じて作ったというよりは、裏側はORMかなにかのモデルと1:1対応してるみたいな感じなんですか?
大木:そうですね。先にサーバ側のモデリングがFIXして、その持っているデータは変わらないけど、View側でどう見せるかというのが変わる状況だったので、サーバの人がGraphQLの中でぜんぶAPIを実装して、それをフロントの人が使うみたいな感じでしたね。
質問者1:ありがとうございます。
司会者:ありがとうございました。それでは時間になりますので、質疑応答のお時間はこれで終了とさせていただきます。あらためまして、大木さん、ありがとうございました。
(会場拍手)
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには