1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

DjangoとReactへ進むための現状の問題点

Posted at

はじめに

AWS試験のSAA試験も終わって、いい加減プログラミング言語の方に戻らないといけないので改めて方向性を確認するためにまとめる。
とりあえずJS、TypeScript、React、Python、Djangoに絞りたい……。

現状の問題点

  • Django(というよりサーバーファーストでアーキテクチャを構成する場合)とフロントファーストのアーキテクチャの統合は難しい

サーバーファーストでの問題点

  • TemplateにまたがってJavascriptがインラインで分散(Templateに直接書き込む形)してしまうので該当のコードがどこにあるのか検索しにくい
  • ベースとなるTemplateにJSファイルを大量にロードするので、ページサイズが大きくなりページレベルの依存関係の理解が困難になる
  • ライブラリを管理するためにWebpackやnode_moduleを使わないので、JSにおいて適切な依存関係の構成や管理ができていない

クライアントファーストでの問題点

クライアントファーストはJSフレームワーク(わかりやすい例でReact)を使い、サーバーエンド側はあくまでAPIとして管理する手法。
React、Vue + Django Rest Frameworkのような構成。
JSフレームワークを使いつつ、Djangoも使いたい! という場面で一見有効に見えるが問題も結構ある。

  • CORSを設定が難解

クライアントファーストで完全にフロントとサーバーを分離する場合、オリジンの問題がある。
例えば開発環境においても大体、フロントがlocal3000でサーバーがlocal8000と分かれてしまうので、こうなると当然Frontで出したサーバーAPIへのリクエストはXSS、CSRF対策でエラーになってしまうという問題がある。
なのでCORSを設定しないといけないのだが、それをフロント側でやるのかサーバー側でやるのか難しいところがある。

  • サーバーサイドのフレームワークを利用する意味がそもそもなくなる

UI全体をJSフレームワークに担わせることで、Templateを一切しなくなる。
そうなるとせっかくサーバーサイドであったテンプレートやフォーム(例えばDjangoでCSRF対策する際は、Templateに1行書き足すだけで済む)のサポートの恩恵を受けることはできない。
その他でもView、Form、組み込みの認証機能等も使えないのでそれなら別にサーバーサイドはいらないのでは? となる。
こういうところの一つのアンサーとしてFlutterなどが存在するのも頷ける。

  • 認証問題

クライアントファーストにしたいということの動機としては基本的にSPAを構成したいというのがあると思う。
ただし、SPAの場合認証にはTokenを利用したものが殆どになる。
このToken認証が曲者で適切にCSRF、XSS対策をしないといけないのはもちろんのこと、SPAは基本的にセッションを使わないステートレスな構成になってくるはずなので認証状態の管理にこのTokenをいつでも利用できるような状態にしておかないといけないのでこのTokenを保管しておかないといけない。
しかし、このTokenはlocalstorageに保存すれば簡単に抜き取られ、Cookieに保存しようとすればHttpOnlyにしようとすると今度はフロント側からアクセスできなくなって利用に困るという難点があり、Cookieをサーバーに渡すのにも苦労する。
ついでにいうとそもそもToken認証はTokenを外部DBにでも保存しない限り、セキュアではないのでは? という議論もあったりする。
そして何より大変なのがこのような問題に対する対策を自分で実装しないといけないことだ。
サーバーファーストであれば認証なんてフレームワークがさくっと解決してくれる分、これは結構しんどい。

  • APIを作る手間が発生する

例えばDjango Rest FrameworkならView.pyの他にSerializerとAPIエンドポイントを作らないといけない。
で、このSerializerをViewに読み込ませる……と結構手間だったりする。
しかも、これをModelごとに作らないといけないのでリレーションを行っていたりModel数が多かったりすると作業量はえらいことになる。
開発・ビルド・デプロイのセットアップも難しい。

  • 特にDjangoにおいてはまだクライアントファーストは未開拓な部分が多い

もともとPythonなので、Pythonを扱える人がわざわざこれでWebアプリを作ろうという人たちが中々出てこないという身も蓋もない事実。
なのでフロントファーストでDjangoを利用するためのアレコレ、特にライブラリやプラグイン周りがRailsやPHPに比べて圧倒的に少なかったり、あっても更新が途中で止まっていたりと結構辛い。

ハイブリッドアーキテクチャという考え方

というわけで、現状DjangoでJSフレームワークを使うには結構ハードルが高いというか課題が多すぎる。
なので、その課題を解決するための視点がハイブリッドアーキテクチャになる。
具体的にはプロジェクトレベルではなく、ページレベルでクライアントファーストなのかサーバーファーストなのかを選択するということをする。
例としては認証やフォームはDjangoのTemplateを使い、JSフレームワークを利用するような複雑であったり、動的なページを作りたい場合はJSフレームワークでページを作るなど。

つまり

  • JavaScriptをほとんど使わないサーバーファーストのDjangoページ(ログインフォーム)
  • TemplateにクライアントファーストのJavaScriptをBuildしてきたページ(動的なページやSPAなページ)
  • その中間のもの

という3つの考え方でページを作っていく考え方がハイブリッドアーキテクチャになる。

これから

とりあえずプログラミング言語の方はハイブリッドアーキテクチャを理解するためにもJSとPythonをちゃんと身につけようと思ってます。
というのも結局TypeScriptがわからなければReact……というよりJSフレームワークをキャッチアップし続けるのは難しいであろうということと、Webpackについても理解を深めないとハイブリッドアーキテクチャへ進むこともできないので。
Pythonは性にあっているのとある程度使えると応用も効きそうなので。
特にPythonについておすすめの教材と情報源とかあったら教えて下さい。
まずはJSかな……

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?