フロントとバックの両方でJavascriptを使うメリットと、実行する処理の使い分けの基準ってどこにある？
BlueSchnauzer前置き
ここ数年、メインの業務が開発なのですが、
以前、参画していたWebアプリ開発の案件が、
バックエンドはC#、フロントエンドはJavascriptとjQueryを組み合わせるという、
ちょっと古めの構成でやっていました。
バックエンドの開発は結構やったけれど、
フロントエンドの知識は古いものしかないなと思い、
キャリアのことや自分の興味のため、JSのフレームワークでの開発について学び始めました。
(Node.js、Svelte(SvelteKit)などを選択)
JSのフレームワークを調べるにあたり、
Node.jsはJavascriptをバックエンドで動かすための実行環境であること、
Next.js、Nuxt.jsやSvelteKitではJavascriptを用いて、
フロントエンドだけでなく、バックエンドの処理も書けることを知りました。
ここで、ふと以下のことを疑問に思いました。
- そもそもJavaやC#などのバックエンド用の言語に比べて、Javascriptって実行速度が遅いんじゃなかったっけ？
- 個人開発なら、Javascriptが得意でバックエンドも同じ言語で書けるのはメリットだけど、
チーム開発や商用サービスの場合も同じことが言えるのか？ - フロントもバックもJavascriptを使えるなら、フロントとバックでも実行できる処理はどっちに任せるべき？
ここら辺に唯一の正解は無いと思います。
色々調べた結果をまとめて、
順不同に疑問に思ったことを自分なりに納得できればいいかなと考えてます。
(JavaやC#が最強(？)なら、バックエンドをJSで書く必要ないし、
JSが最強ならバックエンド用の言語も不要になる)
BlueSchnauzer
- そもそもJavaやC#などのバックエンド用の言語に比べて、Javascriptって実行速度が遅いんじゃなかったっけ？
1個目の疑問がいきなり難題というか、
データIOを踏まえると、この言語が最速！となっても、優位性が大きくならない可能性もある。
それに同じ処理を、別々の言語でそれぞれ最適な実行方法で確認するのは一苦労。
(そのくらい検証すべきだけど)
これに関連して、VSCodeの開発記事が興味深かった。
ざっくり書くと、
VSCodeでは独自のデータ構造(PieceTableの拡張版)を利用しており、
当初はC++でデータ構造を管理する予定だったが、
C++のデータをTypescriptに変換する際のコストが予想よりも大きく、
Typescriptでデータ構造を保持するようになったらしい。
(VSCodeはElectronで作られている)
C++とJSだと単純な速度で言えば、
C++の方がより速いはずだから当初はそちらを選択したはずだが、
実装したい処理や、その周りのIOのコストを考慮する必要がありそう。
ただ、上記の記事だけだと、
実装したい処理によってはフロントでJSを使って実行した方が速いものもある、
という話なので、バックエンドでJSを使うメリットにはならない。
BlueSchnauzer
- 個人開発なら、Javascriptが得意でバックエンドも同じ言語で書けるのはメリットだけど、
チーム開発や商用サービスの場合も同じことが言えるのか？
ここに関してはプロダクトによる、としか言えなさそうな感じはある。
私が何か新しくWebアプリを作るとなった時は、
恐らく規模も小さいはずで、フロントとバックでアプリを分けるのも面倒になりそうなので、
SvelteKitとかを選択して作ることになりそう。
商用サービスの場合は、
Typescriptに慣れた開発者と、サーバー用言語に慣れた開発者を別々に探す必要も無くなる。
(これだけ書くとワンオペに見えるが)
正直この辺りは、サーバーサイドレンダリングのことを踏まえて考えた方が良いかもしれない。
SSRはNext.jsやSvelteKitを使う際のメリットの一つだと思うし、
それを踏まえて、バックエンドの処理をどこまで任せるかを考えたい。
(DB操作はバックエンド用言語で作って、受け取ったデータをSSRで表示するとかがありそう？)
BlueSchnauzer
- フロントもバックもJavascriptを使えるなら、フロントとバックでも実行できる処理はどっちに任せるべき？
一番気になる部分。
フロントとバックを併せて開発できるフレームワークがあり、
実際にそれを使った方が楽な機会もたくさんありそう。
だが実際に開発する際、
フロントとバックのどっちでも実行できる処理はどちらに任せるべき？
前提にあるのはフロントエンドでしかできないのか、バックエンドでしかできないのかの区別。
以下が基準になりそうだと考えている。
- DOM操作
- DB操作
- ビジネスロジック
- コストの高い処理
DOM操作
フロントでしか実行できない。
ブラウザがDOMを操作するために実装している言語がJSしかないため。
DB操作
これはもちろんバックでしか実行できない。
ビジネスロジック
ビジネスロジックが具体的に何かと言われると少々自信が無いが、
DB操作やアプリのコアになるルールを指すはず。
このようなビジネスロジックをフロントに記載した場合、
最悪、ユーザがそれを書き換えてアプリケーションの実行結果を変化させることができる。
そのため、このような処理はバックに書くべき。
コストの高い処理
なんとなく挙げたが、コストの高い処理、について整理してからまた考えたい。
フロントでの実行は各ユーザのブラウザ上で、バックでの実行はWebサーバー上で行われる。
つまりはフロントは分散して実行可能だが、バックは集中して処理が実行されることになる。
前提として各ユーザのブラウザよりも、
Webサーバーの方が処理速度は速いはずなので、そちらに任せるのがベターな気もするが、
各ブラウザで分散して処理した方が良いケースもあるんだろうか？