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