00:05
はい、みなさんこんにちは。株式会社ゆめみでチャレンジ取締役をしております。キースことくわはらです。
Web 業界のなんでも雑談室へようこそ。
この番組では、Web 業界に関することや、様々な雑談などの情報を発信していきたいと思います。
第88回ですね。第88回は、モダンなフロントエンドの開発とは、というタイトルでお話ししたいと思います。
はい、
社内の有志のフロントエンドエンジニアメンバーで、
ある日、営業的な観点で、今後のフロントエンドエンジニアに何ができるかということを、
雑談ベースで話をしていたんですね。
その中で、営業のサイドの方から質問があったんですけど、
そもそもフロントエンドにおけるモダンって何?みたいなことを聞かれたんですね。
言われてみれば確かにそうで、僕らも当たり前のように普段使ってますけど、
そもそもモダンって何?っていう定義を、ちゃんと言語化したことなかったなというのがあったので、
この議論をしてみたんですけど、すごく面白かったですね、これが。
で、みんな結構認識はわりと近かったりして、それもそれでわかって面白かったんですけど、
この情報とかっていうのは、外にも発信してもいいなと思いましたので、
今回これ独断でまとめたのがこの収録になりますね。
今後改めてメンバーでYouTube配信するかもしれないですけど、
あくまで今回は個人の意見なので、参考程度に聞いていただければなと思っております。
もちろん私が間違っている可能性もありますし、
これはモダンでないよとか、いやいやここはモダンに加えていいでしょみたいなところとか、
なんか忌憚なくコメントいただけると、私だけではなくてこの聞いている方、
他の方の学びにもなるので、ぜひぜひコメントをいただけるとありがたいなと思っております。
でですね、先前提として、モダンという言葉ありますけど、
この本来の意味がですね、現代的か近代的みたいな意味があります。
なんですけど、これちょっと僕の中でしっくりこなかったので、
この放送ではですね、現代の主流という意味でモダンという言葉を定義しようかなと思っております。
では行きましょうかね。
ではモダンの話をする上であるんですけど、
大前提としてですね、これフロントエンドとか関係なしに、
ソースコードのバージョン管理することは前提ですよねっていうふうに思っております。
特にですね、しかもGitを使うことが前提ですね。
厳密に言うと分散型バージョン管理できてますかっていうことです。
Git以外にそういうツールがあるのか僕はちょっと知らないんですけど、
まあでもほぼデファクトと言っていいのはGitだと思うので、
Gitを使っているのが前提ですね。
もちろんサブバージョンというものもありますけど、
サブバージョンはさすがにモダンと認める人はほぼいないんじゃないかなと思っております。
コンフリクトの嵐が起きた時代もありましたので。
もちろんでもサブバージョンがダメだっていう意味ではないですし、
使える現場とかケースもあると思うんで、一概に言えないですけど、
ソースコードの管理としてはサブバージョンではちょっときついかなっていうのはありますね。
あとはGitを使うというところで、
プロパイダーとしてGitHubを使うのもほぼデファクトと言っても僕は良いのかなと思っていますが、
03:04
プロジェクト単位ではGitHubではなくてGitLabを使うか、
もしくはBitBucketを使うとかいろんなケースあると思うんですけど、
何かしらGitを使っているってところが重要なのかなって思ってますね。
じゃあ本当にフロンテンドの話に戻りたいと。
思いますが、まず歴史的に話をちょっとしたくて、
従来のウェブアプリケーションの開発の主流っていうのは、
一つのサーバー上で動くモノリシックなアーキテクチャというのが、
昔からずっと来てたのかなと思っていますし、
これが主流だったなというふうに感じています。
いわゆるMVCモデルってやつですね。
モデルビューコントローラーってやつですけど。
のようにデータベースのやり取りとかも、
ビジネスロジックを含めたものも、
あとはテンプレートですね。
いわゆる側の話ですけど、
ビューの話をすべて一つのフレームワークを使って作っていた。
っていうのがモノリシックっていうものの実態としてありますけども。
いわゆる例えばPHPっていう言語で言うとこのララベルフレームワークですかね。
現代で言うと。
昔はいろんなフレームワークがありまして、
ケーキPHPもあったりとかコードイグナイターとかフューエルPHPとかいっぱいあったんですけどな。
そういうフレームワークを使ってロジックもテンプレートの一緒枠体に作っていたっていうところですね。
今のララベルだと画面はブレードテンプレートエンジンを使うんだと思います。
昔はツイーグとかスマーティとかもあったと思うんですけど、
今のちょっと僕PHP書いてないんで主流が何かよくわかってないんですけど、
ブレードなんでしょうねってなんとなく思ってます。
このケースだといわゆるフルスタックエンジニアとか、
もしくはもうちょっと現代的にマルチスタックとかフルサイクルエンジニアとか言われる人たちがいると思うんですけど、
要は一つの分野にこだわらないでいろんなことを何でもやる人っていうエンジニアがいて、
その人たちが開発するケースが多かったんじゃないかなと思っております。
でですね、画面のみを一応フロントエンジニアが担当することもできなくはないと思っていて、
このMVCモデルの場合ですね。
まあそのサーバーサイドの言語とかそのフレームワークの仕様を理解する必要がでもその代わりフロントエンジニアでもあるのかなと思っています。
じゃなければフロントエンジニアはひたすらHTMLを書いて、
そのサーバーサイドの人がそのHTMLをテンプレットエンジンにまた移植というか移行するみたいな手段が出てくると思うんですけど、
まあこれは効率が悪いですし、よろしくないと思っていて、
最初からじゃあテンプレットエンジンのまま書けばいいじゃんって話になるんですけど、
そしたらそれってそもそもフロントエンドの人の仕事なの?ってちょっと思ったりはするので、
まあ少なくともこれをモダンなフロントエンドの開発と認める人はいないと思いますので、
これも違うよなっていうところですね。
なのでいわゆるモノリシックなアーキテクチャーっていうのはモダンではないと僕は思っています。
じゃあ現代のモダンなフロントエンドの開発とは何ですかっていうところなんですけど、
まあやっぱ主流といったらSPAですよね。
シングルページアプリケーションの開発に尽きるなっていうのが弊社メンバーともやっぱり一致していて、
いわゆるクライアントAPI形式のアーキテクチャーですね。
これは僕が勝手に呼んでるだけでウェブ側からAPIのコールをしてって感じですね。
06:05
サーバーサイドはAPIを用意しますと、で側は作りません。
でフロントエンドいわゆるウェブとかアプリ、ネイティブアプリとかもしくはそういういろんなクライアントとかあると思うんですけど、
フロントエンド側がそのAPIをコールしてデータを取得して、それをCSSでスタイリングとかして画面に描画する、
レンダリングするっていうのがいわゆるこのアーキテクチャーの主流というのはなんじゃないかなというところですね。
これの大きいのはやっぱその責務をはっきり分けるっていうのがすごくいいのかなと思いますね。
これがモダンかと思いますけど。
クライアント側で側をやって、サーバーサイド側でロジックとモデルをやるというところですね。
たまにJSON色付け係って言われることもありますけど、言えてみようとなって正直思ったりはします。
でですね、なぜSPAを作るのかっていうところですね。
SPAで作るのかが正しいかな。
あると思うんですけど、大きく理由が2つあると思っていて、
こちらですね、先日の有名な花谷さんって方ですね、
どっかの勉強会で登壇されていたスライドに書いてあった通りで、
僕もこれ完全同意なんですけど、
2つあって、1つはUXの向上ともう1つはDXの向上ですね。
前者はユーザーエクスペリエンスの顧客体験の略ですね。
後者はディベロッパーエクスペリエンスなので開発者体験ですね。
この2つが向上されるっていうのでSPAを作るという感じですかね。
従来のモノリシックなアプリケーションですと、いわゆる画面遷移する。
いろんなアプリケーションとかサイト見たら画面遷移みんなされると思うんですけど、
するたびにサーバー側にデータだけじゃなくて画面のファイルごとまるっとそのリクエストすることになってですね。
1画面1画面遷移するたびに画面がフラッシュすることになりますし、
そもそもパフォーマンス化遅いわけですよね。
これがユーザー体験としてよろしくないというところですね。
をSPAにすることで、SPAはシームレスに画面を遷移させることができて、
加えてユーザー操作に応じてその都度その都度データを取り出せずに送ったりして、
画面そのものの更新をするというよりも画面上の特定の値とかコンテンツのみを変化させるという感じですね。
のがあるのでユーザーも出せる時間が短くなるわけですよね。
そもそもシームレスなので画面のフラッシュもしなくなりますし、
これがユーザー体験としていいでしょうという話ですね。
また先ほどお話しした通りですけど、
開発者側の視点としてはちゃんと責務が分けられているというので、
開発のしやすさが格段に上がりますし、保守性拡張性とかも全然考慮しやすくなったなというのが本気で大きいと思いますね。
何よりですけど、昔はテンプレートエンジンも割とロジックを含めて開発することもたまにあったわけですけど、
そのテンプレートとロジックをちゃんと分離するというところが意味合いとして大きいのかなと思っていますね。
なのでテンプレート側にビジネスロジックを持ち込んでいるアプリケーション、
それは正直バッドケースであり悪種だと僕は思っていますけど、
09:02
これをなるべくは避けることができるというのが大きいと思っていますね。
あとはですね、SPAという単語が出たので、ついでに言うとSSRという単語も出てきたと思います。
昔はほぼ必須と言われていて、いわゆるSEOの観点だったりするんですけど、
この辺がぼちぼち必須じゃないだろうなというところで、SSRは別にいらないんじゃないという議論も最近出ているんじゃないかと思います。
弊社でもSSRをすることはだいぶ減ってきたのかなという感じはしますね。
従来はですけど、Googleのクローラーですね、GooglebotがJavaScriptを実行できるわけではなくて、
SPAのようにJavaScriptでページとかを完全に制御していくというアプリケーションに対しては、
SEOの対策を別途用意する必要があったわけですよね。
その方法の一つとしてSSR、サーバーサイドレンダリングという手法があったわけなんですけど、
Googleクローラーも日々進化しておりまして、SPAでもしっかりインデックスが効くようになってきたわけですね。
それがあるからこそ、SSRも今後はいらないんじゃないのという話が今出てきている感じですね。
あとは今SSRではなくて、ページ単位でサーバー側でレンダリングするかじゃないかということを制御できる、
プリレンダリングという手法が増えてきているような印象が私としてはありますね。
プリレンダリングというのはGoogleクローラーがウェブページにアクセスしたときに、
そのページをサーバー側でレンダリングして静的なHTMLファイルとしてキャッシュをさせるという感じですね。
これによってGoogleクローラーにインデックスさせることもできるよという話ですね。
最近で言うとNext.jsというフレームワークがあると思うんですけども、
こちらのメイン機能の一つがプリレンダリング。
もっと言うとNext.jsはプリレンダリングフレームワークですよみたいなことを公式でも歌っていたりしますね。
というところでプリレンダリングも結構モダンと言っても良いのかなと思ったりしています。
あとはまだ終了にはならないし開発中のお話なんですけど、
最近ですねFacebook借金制のリアクトライブラリーがあると思うんですけど、
リアクトに新たな概念としてページじゃなくてコンポーネント単位でサーバーサイドにレンダリングするという
リアクトサーバーコンポーネンツという機能が絶賛開発中ですよというのが発表がありましたね。
これが次また来るのかなと思ったりしていますね。
これの大きなメリットですね。
この機能の大きなメリットとしてはAPIからデータをフェッチするコンポーネントについてサーバー側でレンダリングしてしまおうというものなんですけど、
これのメリットとしてはバンドルサイズがかなり小さくできることですね。
ものによってはこのまま全部サーバーサイドにしてしまえばバンドルサイズがゼロになるみたいなことも一応理論上あり得るということもあってですね。
これは結構大きいのがあると思っております。
またはクライアント側で変更された状態、ステートをそのままクライアント側でも保持できるというのが大きいのかなと思っていますね。
12:02
あとはレンダリングスピードも速くなると。
バンドルサイズが小さくなればレンダリングも速くなるよというのもあるし、
ファイルサイズだけじゃなくてレンダリングというのも速くなるというところが一応歌っている感じではありましたね。
ちょっとMacもまだ詳しく追い切れてないですし、機能の詳しいところまで覚えてないので、
その辺はちょっと皆さんでも調べてみていただければなと思っておりますが、
結構面白そうな話で、これはこれでちょっと来年に向けて注目していこうかなと思っている次第ですね。
ちょっとモダンからいろいろ外れてしまった。
最新の話とかサーバーされるんだけど、話にちょっと行ってしまったので、
モダンの話に戻したいと思いますが、
ちょっとアーキテクチャの話が出てきたと思うので、
アーキテクチャの話をもう少し深掘りしたいと思いますが、
モダンなフロントエンドの開発でいくと、
メインは一つUIライブラリを決めてですね、
あとはそれについて必要なものをアプリケーションとか、
プロジェクトに応じて必要なものをエコシステムに頼るというところが、
今のモダンなんじゃないかなと思っていますね。
すなわちですけど、サードパーティー製のライブラリとかをどんどん導入していって、
開発環境を整えたりとか、必要な機能とかもそれに揃えていくというところですね。
使うものも有定でもUIライブラリのメインは、
ほぼほぼリアクトかVue.jsの2択になるんじゃないかなと感覚的に思っています。
いろんなコミュニティー参加者や他の方の意見とか話を聞くと、
この2つの名前がよーく出てくるのかなと思っています。
もっと言いますと、それらをラップしたNext.jsとかNext.js、
この2つなんじゃないかなと思っております。
どちらもCLIがすごく重要視していたりとか、
サンプルのプロジェクトが結構用意されていたりというのもあって、
こいつらを使うことで開発スタート時に悩むこと、
設計とかどうするみたいなディレクトリ構成とかっていうのが、
ほとんどなくなったっていうのがやっぱり大きいのかなって思っておりますので、
この2つが今のモダンな開発の主流なんじゃないかな、モダンさってあるんですけど。
一応、Angularという選択肢もあるとは思いますけど、
こちらは僕の観点でいうとUIライブラリっていうか、
ちゃんとしたフレームワークっていう認識ですね。
ですので、Angular使う場合は、
サードパーティー性のライブラリをあれもこれも調べたりとかして入れるっていうことは、
そんなないんじゃないかなと思っております。
ほとんどの機能とか必要なものはAngularが最初から用意してあって、
それら1個1個モジュール化をされていると思うので、
それのどれを使うって話になると思うんですけど、
というところかなと思っています。
なので、先の2つに比べたら、
これは1つもうAngularだけで成り立ってしまうっていうのは大きいですけど、
一応、Angularも言うて、
バージョン2って言ったらあるですね、Angularからですね。
15:01
からはもうUIに特化したところもあるので、
僕も1回使ってみたんですけど、
ちゃんとカッチリ作れるっていうか、そこが大きいのかなと思います。
あとはリアクティブなところですね、ステート管理。
というところが僕は結構面白くてですね。
一度ハマるとドハマりする人もいらっしゃいますし、
これが嫌いっていう人もあって、
これらへんは賛否両論なところはありますけどね。
あとは海外でこの近年爆発的に人気が伸びてきているスベルトっていうものもあって、
この辺を使うのもアリなんじゃないかなって思っております。
スベルトもどんどん進化していますし、
一応Sapperっていうプライブラリ持ってたんですけど、
これが今後なくなって、
移植されるっていうところがスベルトツールに統合されていくって話もあって、
今後スベルトも全然注目して良いのかなと思っておりますね。
もう一個だけアーキテクチャの話を深掘りすると、
近年で言うとやっぱりBFFの話をしないといけないのかなって思っております。
モダンなフロントエンドの開発では、
今後BFFは避けて通れないだろうっていう話がちょっと前に言われていて、
僕もその通りだと思ってますし、今もこの話は続いていると思っていて。
必須とは言わないですね、もちろん。
ただ必須じゃないですけど、
これを使うことが当たり前じゃないし、
絶対入れてねっていうわけじゃないです。
これあくまで必要であるかとか、
導入することでプロジェクトの開発体験とか、
いろんな恩恵を得られるから入れるっていうのは正しいと思います。
このスタンスは大事ですけど、だからといってあるんですけど。
BFFの選択肢として何があるかってことなんですけども、
現代はやはりグラフQLが一番強いのかなと思っておりますね。
僕も今年のプロジェクトをいくつかで、
グラフQLのプロジェクトも経験して、
やはりBFFの選択肢として、
グラフQLの話が大きいんだなって未だに思っています。
まずはグラフQLをどうやって使うかっていうところなんですけど、
この辺に関しては一応Apollo Frameworkが一番人気なんじゃないかなと思っています。
一応NPM Trendsっていうサイトがあって、
そこでいろいろグラフQL周りのところとかのツールとかライブラリ調べたんですけど、
あくまで群を抜いていたのがやっぱりアポロですね。
アポロだったのでこの辺かなと思っています。
まずアポロ自体はちょっと重かったりして、
機能もすごく揃ってるんですけど、
機能過多なところもあったりするので、
ライトなプロジェクトとかアプリケーションであれば、
アポロじゃなくて別のものを使うっていうのも正しいのかなと思っていますね。
あと個人的にはですね、僕はAWS結構好きなので、
AWSのAppSyncも選択肢として全然ありなんじゃないかなってちょっと宣伝したいなと思っています。
そんなところですかね。
アプリケーション…アプリ…アーキテクチャーですね。
今日神々で申し訳ないです。
アーキテクチャーの話が終わったら、
次はデプロイ先の環境の話とかになるかなと思っていますね。
先ほどもお話しましたけど、従来はサーバーを用意して、
そこにウェブサーバーと、
ApacheもしくはNginxみたいなものをインストールして、
その上にフロントエンドのアプリケーションのソースコードとかを配置して、
18:03
配信をしていたというところがあったと思うんですけど、
現代はそういうことじゃなく、
静的ファイルに一回フロントエンドのソースコードをビルドしまして、
それをホスティングするってことはほとんどじゃないかなと思っています。
ホスティングサービスもだいぶ増えてきておりますし、
結構充実してきたなと思っていて、
ホットなものをあげると、
Firebaseホスティングとかあったりとか、
Netifyとか、もしくはAmazon S3とか、
個人開発とかライブラリの開発であったら、
GitHub Pagesも全然ありだなと思っていますね。
こんなところでホスティングするものも全然増えてきて、
なんていうのが大きいと思っています。
もちろんサーバーサイトレンダリングするっていうことが必要なプロジェクトもあると思うので、
その場合はそのためのサーバーの用意が必要だと思います。
ですけども今はそうですね、
コンテナ化が進んでいまして、
クラウドでサーバーEC2みたいなのをガンと用意するというよりも、
ここが必要なんですけど、
DockerでSSR用のコンテナを1個用意して、
そこにその辺のソースコードをまるっと入れておいたものを用意して、
デプロイするっていうのが主要なのかなと思っていますね。
これどっちかっていうとデプロイの話になってしまいますけど、
な感じでサーバーを用意したけど、
そこにソースコードをまるっとバンと送っているよりも、
そのコンテナイメージをそこにボンと置いていくっていうのが、
あと起動するのが多いのかなと思ったりしますね。
EKSとかKubernetesみたいなのを持っていたりしますので、
どんどんどんどんコンテナに集約して、
それをまるっと一元管理するっていうのが楽だよねって話はありますね。
あとはですね、静的ファイルにビルドするってよく言いますけど、
なんでそれをするのかっていうのがあります。
理由もいくつかありますけど、
大きいのはCDNでコンテンツをキャッシュして、
パフォーマンスを上げるっていうメリットが大きいのかなと思いますね。
やっぱり静的ファイルですので、
キャッシュ化してどんどん高速化するのがよいし、
サーバーに行かなくても返せるのであれば、
そのCDNで返してしまえば、
ユーザー体験もいいと思うので、この辺かなと思いますね。
あとはビルドする場合、
メインで使うUIライブラリにもよるんですけど、
ほとんどの現場では、
ビルド前に一回ソースコードをビルドするとき、
ビルド後にバンドルをすると思います。
いわゆるいろんな静的コンテンツをガチャンと
一つのファイルに集約してしまって、
それを一個だけ読み込むみたいな感じですね。
これが大きいし、これをするメリットはたくさんありますので、
今はこれが主流なのかなと思っています。
バンドルのツールもたくさんあって、
ロールアップもあったりとか、
スノーパックとかパーセルバンドラーとかあったりしますけど、
ほぼデファクトスタンダードは
Webpackと言っても過言じゃないのかなと思いますね。
そもそもメインで使うUIライブラリの
デフォルトの環境自体が
Webpackに依存していることがほとんどだと思いますので、
この辺かなと思います。
ちょっと長くなってきましたけど、
もう少しで終わりますね。
デプロイ環境の話をしたので、
最後デプロイそのものの話、
手段の話ですね。
もうしないといけないかなと思っています。
21:03
こちらも今はCACDツールとかサービスが
結構拡充してきておりまして、
自動でビルドをデプロイすることが
フロントエンドでも当たり前だろうなと思っております。
ローカル環境とかどっかの環境でビルドして、
そのものを別のところに手動でアップするとか
ナンセンスですからね。
全部自動化したいよなと思っていますね。
どんなツールとかサービスとかいうと、
例えばAWSであればコードパイプラインとかを使うとか、
もしくはアンプリファイを使うとか、
あとはサークルCIみたいな手もありますし、
ネットリファイもそもそも同様に
自動でやってもらうみたいな
CIGDの機能がありますからね。
この辺を使うのかなと思います。
共通した使い方としましては、
例えばGitHub使っている場合は
GitHubの特定のリポジトリと
そのサービスを紐づけまして、
そこにフックをかけてGitHubにプッシュするとか、
もしくはメインブランチに
Appleリクがマージされましたっていうことを
トリガーに自動で走らせてビルドデプロイ
みたいな感じですね。
そういうのが主流だと思っています。
一応そういうCGDの中に
ジェンキンスっていうツールもあるんですけど、
フロントエンドの開発でこれ入れるのは
さすがにちょっとないかなと思っています。
ないっていうとケースとして当てはまらないし、
ちょっと重いし、
用意するのが面倒くさいのが正直あると思うので、
ジェンキンスはないのかなと思っていますね。
というところですかね、
ちょっといろんなこと喋ってきて
かなり長くなってしまったんですけど、
こんなところがフロントエンドの
モダンなのかなと思っております。
今後もどんどん変わると思います。
改めて申し上げますと、
私個人の意見とか感想ですので、
忌憚なくコメントいただけると嬉しいですし、
私自身が間違っていることもあるので、
ぜひご指摘いただけるとすごくありがたいと思います。
この手の話っていつでもやっていいし、
今後もどんどん役に立つ話だと思いますので、
また他の方とも議論してみたいなと思っているところもあるので、
もしよろしければ誰かお話させていただければなと思っております。
今回は以上で終わりたいなと思っております。
また何か聞きたいこととか話して欲しいことがございましたら、
いつでもれただきコメントの内容をお待ちしておりますので、
お聞き方に投げていただければなと思っております。
ではまた次回の収録でお会いしましょう。
バイバイ。
