はじめに
Play FrameworkをバックエンドAPIとして使って、Reactをフロンドエンドとして使ったときに思ったことです。
データの計算はバックエンドAPIとWebフロントエンドのどちらがやるべきか
sandboxとproductionのDBの差分をWebフロントエンドで計算していました。
これはバックエンドAPIにデータ計算をさせるべきかなと思います。
理由はロジックが複雑になってくると、型がないのでバグが紛れ込む可能性が上がることです。特にフロントエンドはUIの変更が頻繁に発生していたので、毎回何かの型がタイプミスマッチが出てChrome DevToolsのコンソールが真っ赤になっていました。
Webフロントエンドのリクエストパラメータを信頼しすぎない
Webブラウザ上からバックエンドAPIを叩いているだけなので、バックエンドAPIが許可していればどのようなリクエストパラメータでもリクエストできます。そして、Webブラウザ上実行されている性質上データの書き換えが可能です。バックエンドAPIのリクエストパラメータ取得時と業務ロジックで適切にバリデーションをしておけば問題ありませんが、Webフロントエンドのデータを盲目的に信じてしまうのはよくありません。バックエンドAPIはリクエストパラメータを適切バリデーションしましょう。
バックエンドAPIとWebフロントエンドは切り離すべきか
WebフロントエンドはバックエンドAPIに置いています。物理的に同じサーバーの同じアプリケーションで動作しています。/を GET することで、WebフロントエンドのJavaScriptを取得する仕組みです。
バックエンドAPIとWebフロントエンド用のJavaScriptファイルは同じアプリケーション上に置いています。
バックエンドAPIとWebフロントエンドはプロジェクト自体を切り離してしまって、別々のサーバで動作させるべきかなと思います。
以下の理由があります。
- バックエンドAPIの開発とWebフロントエンドの開発を分けることができる。別々のリポジトリで管理することでプロジェクト全体の見通しが良くなります。
- バックエンドAPIとWebフロントエンドを別々にリリースできる。Webフロントエンドだけに変更があった場合でも、バックエンドAPIに不必要な再起動が発生することです。
- Webフロントエンドのレスポンスタイムを短くできるはず。Webフロントエンドはただの静的ファイルなので、ApacheやNGINXなどを利用するようにした方が速度は出ると思います。
終わりに
同じような構成でアプリケーションを作る場合は上記についてどのように設計すればいいか考えてみたほうがいいかもしれません。