【学習ステップまで解説】Django×Reactで作る”モダンなWebアプリ”とは
1. はじめに
こんにちは、ぎーたかです。
今回はフロントエンドフレームワークについて記事です。Djangoの開発者が学習することで作れる”モダンなWebアプリ”について解説していきます。
筆者自身のフロントエンドフレームワークを学んだ実体験から、Djangoと組み合わせることで作れるWebアプリ、またモダンなWebアプリのメリットにも言及しつつ、解説していきます。
フロントエンドフレームワークとは、Webアプリの見た目の開発に特化した開発ツールです。決まりに従って書けば、素のHTML/CSS/JavaScriptでの実装よりも、効率良く・高機能なWebアプリ開発を行えます。
筆者自身の初めてのWeb開発学習はDjangoからでした。
初めてのポートフォリオは、見た目の実装も全てDjango内で開発しました。
その後Web開発のスキルを向上させたい思いで、モダンなフロントエンド開発に挑戦してReactを習得し、実際にDjango×Reactの組み合わせでWebアプリを開発した経験があります。
そのためWebアプリを①Django単体で作る場合と、②DjangoとReactを組み合わせて作る場合、これらの差はある程度理解していると考えています。
Web開発者なら誰でも参考になる記事ですが、特に「フロントエンドフレームワークを学んでみたい」、「Django開発者としてスキルの幅を広げたい」と考えている方にとって、読む価値のある記事になっています。最後まで読んでくださると嬉しいです。
まずは、フロントエンドフレームワークの種類について、どういうものがあるのか解説するところから始めましょう。
2. フロントエンドフレームワークの種類・特徴
一口にフロントエンドフレームワークと言ってもたくさん種類があります。いくつか例をあげておきましょう。
■有名なフロントエンドフレームワーク
・React...2011年に登場、Facebookが開発、JavaScriptフレームワーク
・Angular...2012年に登場、Googleが開発、JavaScriptフレームワーク
・Vue...2014年に登場、Angular開発者が開発、JavaScriptフレームワーク
・jQuery...2006年に登場、JavaScriptライブラリ集
共通点は、DjangoなどのWebフレームワークのフロントエンド開発に利用できること。相違点はたくさんありますが、jQueryは他のフレームワークとの違いが大きいです。
jQueryはあくまでJavaScriptライブラリ集で、素のJavaScriptの書き方を簡素にする程度のことしかできません。一方、React/Angular/VueはJavaScriptフレームワークで、Webアプリをまるっと作れる程の高機能性を持ちます。特に、フロントエンド開発の機能が豊富で、それを活かしてモダンなフロントエンド作りに応用できます。
機能の例として、JavaScriptフレームワークではHTML/CSSの実装もほぼ全てJavaScriptファイルの記述できる記法があります。これは開発時に便利な機能の一例で、開発したフロントエンドのコードの再利用性を向上してくれます。
本来ならHTML/CSS/JavaScriptファイルに散らばっている、フロントエンドのコードをJavaScriptに凝集できるので、別のWebアプリで再利用したくなった時の移植性が非常に高いです。
それぞれのフレームワークで細かな違いに着目すると、これら一つ一つに異なる特徴・適材適所な利用用途があります。
今回の記事の中心になるモダンなフロントエンドには、jQueryは関わりが薄いので話題からは外そうと思います。ちなみにjQueryはオワコン・時代遅れと言われがちですが、使い勝手が良い用途はあるので一概に悪いとは言えません。その辺りを詳しく知りたい方向けに参考記事を貼っておきます。
フロントエンドフレームワークについては少し理解が深まったかと思います。次のパートでは、なぜわざわざDjangoと組み合わせる必要があるのかについて、Djangoの弱点という切り口で解説を続けます。
3. Django単体でのWebアプリ開発の弱点
Djangoはフルスタックフレームワークなので、Web開発に必要な幅広い開発機能を備えています。そのため、どんなWebアプリもそれなりに作れます。
初学者にとっては、1つの開発ツール内で完結できる点は学習コストを少なくできるので、メリットはあります。ですが、逆にそのフレームワークで本質的に苦手な処理をさせている可能性もあります。
例えば、Djangoにも苦手なこと・弱点は、列挙していけば色々あります。
フロントエンド開発で便利な技術（Sass、Babel、TypeScriptなど）を使うための設定が面倒くさい、Python起因で処理速度が遅くなりがち、など。
今回の記事のテーマに沿って一つ取り上げると、『フロントエンドをモダンな仕様で作り込めない』というのは大きな弱点の一つであると言えます。
もし読者の皆さんが、Djangoを学び始めたばかりで、こうした弱点に向き合うスキル習得に時間が割けないなら、まずはDjango単体でWebアプリの形を作れるようになることを目指すべきです。単体で完結できるのがフルスタックFWの利点ですから何も問題はありません。
しかし、フルスタックな側面に頼っている状況は、例えると野球の守備を半分の人数でやっているようなもので、Webアプリのプロジェクトとして美しい形にはなっていません。
もし読者の皆さんが「Djangoで簡単なWebアプリは作れるくらいになった」というレベルなら、今こそフロントエンドフレームワークを習得しDjango技術者としてステップアップを図るべきです。
次のパートでは、この記事のキーワードである”モダンなフロントエンド”について解説します。フレームワークとの関係性や、どんな見た目のスタイルがユーザーに受け入れられるのかにも一歩踏み込んで解説していきます。
4. Django単体では作れない"モダンなフロントエンド"
このパートでは”モダンなフロントエンド”とはどういうものかについて、それが必要になった背景から順序立てて説明していきます。
近年、ユーザーの目が大変肥えています。
読者の皆さんも含めて、おそらくほとんどの人がスマホを持ち、世界中の優れたサービスを毎日365日利用し続けていますよね。
Twitter、Instagram、YouTubeなどはどれも直感的な操作でサクサク動くサービスを提供していて、ユーザーはそれに慣れた反面、使用体験の悪いサービスをすぐに使わなくなっていきます。
このような時代背景で、いいWebアプリとは便利な機能を備えているだけでなく、ユーザーの肥えた目に見限られない使用体験も重視した提供できるサービスを作ることが最低条件になってきます。
そうした使用体験を追求して、フロントエンドの界隈ではモダンなWebアプリの1つの形としてSPA（Single Page Application）というものが開発のキーワードになってきています。SPAの参考記事を貼っておきます。
SPAとは、要はネイティブアプリ（スマホアプリ）の様に動くWebアプリです。スマホアプリの様な滑らかな画面提供を目指した結果、画面遷移で最も時間のかかるページローディングを排除できる様に、アプリ内で1つのURLしか使わないWebアプリのことです。
メリットとして、サービス内の画面遷移が早くなるので、ユーザーにストレスのない使用体験を提供できる点で優れています。
近年のモダンなウェブの代名詞として、このSPAが語られることが多くあるので、”モダンなフロントエンド”≒SPAと覚えておいてもあながち間違いではないかと思います。
一方でこのSPAにもデメリットはありますが、実はそのデメリットを解決できる技術も現れ、実装難易度以外のネガ要素は無くなりつつあります。8. 更なるステップアップ『Next.js』のパートで、解決方法と合わせて紹介したいと思います。
次のパートでは、モダンなフロントエンドを作る為に、フロントエンドフレームワークでできることを解説していきます。
5. フロントエンドフレームワークでできること
近年のコーディングに関する近年の技術発展の動向は①DX（開発者体験：Developer Experience）、②UX（ユーザー体験：User Experience）の2つの切り口の課題解決に関するものが多いです。DXについては一般的によく知られているDX（デジタルトランスフォーメーション：Degital transformation）とは異なるので、違和感があるかもしれませんね。
ざっくりとした理解としては、①は開発者の悩みを解決できる開発サポート技術、②はWebアプリの利用者が気持ちよく使える画面の作成技術くらいに理解して貰えば良いかと思います。
フロントエンドフレームワークも例に漏れず上記の考えで作られており、できることを①・②の切り口でまとめます。なお、筆者が実際に学んだReactを例に列挙した方がまとめやすいので、React前提で列挙していきます。
■①DX面
1つ目、”create-react-app”はReactのプロジェクト作成のコマンドです。
$ npx create-react-app プロジェクト名との実行で、Reactの雛形プロジェクトを作成できます。これはDjangoでいうdjango-admin startprojectコマンドと同じで、Reactの起動に必要なファイル群を一気に構築してくれます。
開発に必要な機能・モジュールもすぐに使える状態で作成してくれるので、簡単にReact開発を始められる点でDX的に優れてるといえます。
◎機能・モジュールの例
開発用コマンド用意…ターミナルで実行できる開発コマンド(build等)を用意
クロスブラウザ対応…ブラウザソフトの違いによる描画結果の差異を吸収
リンター…自作コードの規約チェックをしてくれるlint機能
また、2つ目のnpm・yarnといったパッケージ管理コマンドを使えば、
$ npm install ライブラリ名とコマンドを叩くだけで、新たに追加したくなったライブラリも簡単にプロジェクトに含められます。
これで追加できる便利機能の一例として、”Material-UI”という
Google提唱のデザイン原則に従ったUI素材集といったものも使える様になります。
このようにコマンドを叩くだけで、機能の拡充を簡単に行える点、開発サポートに優れたライブラリが豊富な点はDX性に優れた側面を持つと言えます。
なお、こうした特徴はReactだけでなく、VueでもAngularでも類似のコマンドが用意されているので、フレームワーク間に差はないと考えています。
■②UX面
1点目はどのフロントエンドFWでも備えている機能です。一応、jQueryでも唯一この点だけは備えています。Reactで特徴的なのは2点目で、Webページの更新を必要な部分のみ行える点が非常に強みです。
ちなみにAngularは同じことができず、Vueでは同じことはできます。
ただ、VueよりもReactの方が、描画画面の滑らかさ・描画に用いるJSファイルの軽さ・最終的な画面への表示速度、ユーザーの使用体験に関わる項目を総合的に見て定量的に優れている調査結果があります。
少しずつ、Reactをはじめとするフレームワークの実力について理解も深まってきましたね。次のパートからは、いよいよDjangoとフロントエンドフレームワークの組み合わせ方・動作イメージについて、Reactを例に解説していきます。
6. Django×Reactの組み合わせ方・動作イメージ
実際にDjangoとReactを組み合わせたWebアプリを作る時、どのようにDjango・Reactそれぞれに機能を持たせるかを解説していきましょう。
読者の皆さんには、Django・Reactがどんな役割で機能するのか、完成形のWebアプリの中でどの処理を担っているのかについてイメージを掴んで貰おうと思います。
■役割
まず前提として、DjangoとReactは以下の通りに役割分担して動作します。
■処理イメージ
ReactとDjangoを組み合わせてWebアプリを作成する際、以下の図のサーバー構成で、①〜⑦の処理を行ってWebアプリとして機能します。ポート番号はローカル開発時の分かりやすさのため、それぞれデフォルトで使われる番号を書いておきました。
（※デプロイするときはこの限りではないので注意してください。）
この時、Djangoのサーバーはアプリサーバー、ReactのサーバーはWebサーバーとして機能しています。ざっくり違いを説明すると、WebサーバーはHTML/CSS/JavaScriptファイルをレスポンスで返すサーバー、アプリサーバーはデータベース操作といった動的処理を行うサーバーです。
もう少し詳しく知りたい方向けに筆者が読んで分かりやすかった参考記事を載せておきます。”Webアプリの三層構造”というWebアプリの超基礎になっているキーワードも出てくるので、聞いたことなかったという方は読んでみると良いかと思います。
図の処理の流れを言葉でも説明します。
＜①＞
実際にWebアプリとして動作時の起点は、WebアプリユーザーがReactプロジェクト側（開発サーバーならlocalhost:3000）にアクセスすることから始まります。
＜②、③、④＞
すると、ユーザーPCでは初期画面の描画のためのJavaScriptファイルをレスポンスで受け取り、ユーザーPC内で画面描画の処理が開始されます。
Djangoでのみ開発をしていた方にとっては『え？サーバー側でレンダリングしたHTMLを返すんじゃないの？』と感じるかもしれませんが、JavaScriptはブラウザで処理できる言語のため実はPC側で描画は可能で、この性質を活かして初回ロード時以外はサーバーと通信しないSPAが作れます。
＜⑤、⑥、⑦＞
画面に表示する要素には、アクセス時の状況で変化する箇所も含まれています。JavaScriptには、動的にAPIを叩いてデータを取得し、そのデータを使い画面描画できる機能があります。SPAでもこれを活用します。
このAPIは、Djangoプロジェクト側のサーバーで用意します。コンテンツ表示に必要なデータを返すAPIの実行処理をJavaScriptで行わせ、ユーザーPC側で画面描画を完成させることができます。
これをユーザーのWebアプリ操作に応じて動的に変化させるために、Reactプロジェクトでは、画面の状態に紐付けた変数を用意できます。例えば、図中のメニューバーのアクティブな項目を記憶できる様にもできます。
この変数が変わる度、実行すべきAPIを叩きそのレスポンスを受けて都度画面描画をしていく。SPAではこれを続けることで、Webアプリの状態に応じた適切な画面表示をできる仕組みになっています。
次のパートでは、実装にあたって必要な技術について解説をしていきます。
7. Django×Reactアプリ作成に必要な技術
Djangoで簡単なWebアプリを作れるレベル（下記参考記事の2.学習ロードマップが全部できてるくらい）にある方を前提に、必要技術を解説していきましょう。
①Django REST Framework
Django REST Framework（DRF）は、Djangoのviews.pyで作成したメソッドをAPI化できるサードパーティライブラリです。Reactから叩くためのAPIにURLを割り当てて用意し、実行された際にJSON形式でデータを返すメソッドを作れます。
Reactが作る画面からでもDjangoで定義したモデルを通して簡単にデータベース情報を取得できるので、もしDjangoで作ったWebアプリを作り替えたいとした時は再利用できるコードも多くあるでしょう。
DRFについては、筆者の過去記事で概要と基礎文法について解説した記事があるので、興味のある方は読んでみてください。
また、書籍を通して学習したいという方にはこちらをオススメします。筆者自身がDRFの学習に使いました。日本語で丁寧にまとめられたDRFの情報は、インターネット上にはほとんどなく重宝しました。
②React~基本文法~
基本はJavaScriptベースですが、一部フレームワーク特有の書き方を覚える必要があります。まずは公式チュートリアルを試してみると良いと思います。
一点だけキーワードの補足解説します。
■JSX
JavaScript内で記述できるHTMLだとイメージしてください。HTMLと異なる点は、①JSXを変数に格納できること、②それを別のJSXの中で展開できることです。
ReactはSPAなら特定箇所の要素のみを変更できました。その変更（更新・入れ替え）の対象になるJSXを全て変数に格納して管理したときに、この実装方法のメリットが出てきます。
ページの挙動に合わせた単位で実装することで、見通しの良いコーディングになります。こうした動的な要素ごとにコードを管理する考え方をコンポーネント指向と呼び、フロントエンドフレームワークではこの思想で実装することがデファクトスタンダードになってきています。
とりあえずチュートリアルをやっておけば、コンポーネント指向でコーディングするために必要なJSXの使い方（変数化・展開方法）は理解できると思います。これにより、JavaScriptだけでHTML/CSS/JavaScriptで表現できる基本的なページ作成はできる様になります。
JSXのイメージをもう少し湧きやすくするために、↓の参考記事を読んでみると分かりやすいかもです。『コンポーネントを分ける』のパートを読んでみると分かりやすいかと思います。
③React~発展文法~
こちらは公式チュートリアルには出てきませんが、SPAを作る為には習得しておくべきかと思いますので列挙していきます。
■Axios
JavaScriptでAPIを叩く処理に使うメソッドです。
APIを叩くためのURL・HTTPリクエストメソッド・入力JSON（JSONは不要なこともある）を指定して実行することで、簡単にAPI呼び出しの一連の処理を実装できるメソッドです。
具体的な書き方は今後の記事で解説予定ですが、早く概要を知りたい方向けに参考記事を貼っておきます。ブログ記事ですが、書き方の参考になりそうです。
■Hooks
画面の状態管理の実装のためのライブラリです。状態管理に関わる非常に豊富な便利メソッドを備えています。
状態変数、状態変数を書き換えるメソッドの用意、ウォッチするタイミングの定義、変数・メソッドのエクスポート...と必要な実装はたくさんありますが、全部このHooksという機能を使って実現できます。
こちらは2019年2月にリリースされたReactバージョン16.8からの新機能のため、インターネット上で収集できる知識では少々納得のいく実装は難しいかと思います。筆者はこちらの書籍と、Udemyの教材を参考に学習しました。ご参考までに掲載しておきます。
Reactの必要技術に関しては、今後サンプルコード付きの解説記事を書いていこうと考えているので、そちらもお楽しみにしていただけると嬉しいです。
次にパートでは、『Next.js』について軽く紹介します。
4. Django単体では作れない"モダンなフロントエンド"のパートで存在には触れましたが、Reactで作るSPAにはいくつかデメリットがあります。Next.jsはこれを解決できる手段なので、Reactを使ったSPA作成に取り組むなら知っておいて損はない知識です。
実装には細かく触れずに概要を解説します。将来学習すべき内容の一つとして押さえておきましょう。
8. 更なるステップアップ『Next.js』
ここまでReact・SPAについてアツく解説してきましたが、SPAにはデメリットがあります。デメリットについてまとめられた参考記事はこちら。
筆者の主観で、クリティカルなものを取り上げて解説しましょう。
①初回ロード時の遅さ
通常のWebアプリではDjangoサーバーとの通信のみで画面表示できるところを、Reactサーバーとの通信・Djangoサーバーとの通信・受信データを使った画面描画の待機時間が必要になるので当然ロードは遅いです。
SPAのサクサク動く利用体験をしてもらえるのは、ユーザーの滞在時間が長いサービスである時に限定されるので、滞在時間の短いサービスにはSPAは不向きと言われることもあります。
②SEO（検索最適化）に弱く検索上位に表示されない
ブラウザ検索上位の獲得は、Webアプリの認知向上の一手段として有効ですが、SPAの場合は上位表示を獲得しにくいです。SEOの仕組みは、検索エンジンのクロウラーというページの質を精査してくれるシステムの結果を基に上位表示すべきか判断しています。
SPAの場合、クロウラーが訪れてもWebページをみることができません。アクセスして見れるのは、ユーザーPCで描画する用のJSファイルだけです。クロウラーは自身で描画してWebページとして見られないため、精査もできないという理屈です。そのため、良いWebページなのかを判断してもらえずSEO的には不利な結果になることが多いです。
①②の理由から、SPAは作りたいWebアプリのビジネス用途に合わせて適用しないとデメリットに悩むことがあると言われてきました。ですが、近年は『Next.js』を使ったSSR（サーバーサイドレンダリング）という技術でこの課題を解決できるようになってきています。
Next.jsとは、Reactのフロントエンド開発を拡張したフレームワークで、Reactの機能を拡張して色々できる様にしたものです。その機能の一つにSSRが含まれます。
このSSRとは、初回アクセス時だけページの描画をReact側のサーバーで行う技術であり、この技術を使うことによってSPAのデメリットをそれぞれ解決できます。
「SPAとのサーバー構成の違いまで詳しく知りたい」という方は、下の参考記事を読んでみてください。Django単体、Django×ReactのSPA、Django×ReactのSSRのサーバー構成の違いが図解されていて、とても分かりやすいです。
■デメリットの解決
①初回ロード時の遅さ⇨サーバー実行でき、ユーザーPCでやるよりも高速化
②SEOに弱い⇨クロウラー訪問時も描画済みのWebページを表示し精査可能
これからReact学習を始める方には先の話に聞こえるかもですが、Reactの学習ロードマップの先にこうした技術も存在していることを押さえておいてください。貪欲に技術を習得してご自身の市場価値をグングン向上できるよう頑張ってください！
9. まとめ
いかがでしたか？
Reactを中心的に例にとって、フロントエンドフレームワークについて幅広く解説してきましたが、イメージは掴めましたか？
近年は本当にいろんな学習教材・サービスが揃っていて、たった1つの言語・ツールを使えても高い市場価値にはつながりにくい傾向にあると考えられます。Djangoもその1つでしょう。
そんな時代背景で希少性を高めるには、スキルの掛け算を作るしかありません。どんな業界でも、1人でその業界のスキルをたくさん知っていることは価値があります。Web開発の業界なら、バックエンド〜フロントエンドを幅広く習得してみる、クラウドでのサーバー構築を習得してみる、など。
Reactの習得もその1つの手段だと思うので、もし今回の記事を通して”フロントエンドも力を入れて勉強してみようかな”と感じてくださる読者の方が1人でもいれば幸いです。
次はReactの具体的なサンプルコードを含めた記事を作れる様にしていきます。よかったら次の記事も最後まで読んでくださると嬉しいです。
よろしければサポートをお願いします🙇♂️ いただいたサポートは、クリエイターの活動資金として使わせていただきます😌 活動を通してえた経験を、また記事として皆さんと共有します👍