今回はフロントエンド開発についてです。
手間や制限はありますが、Javascript(＝Vanilla Javascript)だけでフロントエンドシステムは構築できます。
ただし、それなりの手間はかかりますよ！
- 素のJavascript(Vanilla)だけでもフロントエンドとして動かせる
- 参考：フロントエンドとバックエンドの関係について
- Vanillaでのフロントエンド構築を阻む、手間や制限について
- 最終的に何を選択するか？
- 最後に
素のJavascript(Vanilla)だけでもフロントエンドとして動かせる
気になるであろう「手間や制限」は次章以降で解説しますが、先に定義および前提条件を解説します。
説明している段階で、自分のスキルでは、わざわざフロントエンド開発する必要性がなくなるかもしれません。
(PHPやRuby on Railsなどで開発できるのなら、そちらの方が楽ですしね。)<
至極当たり前のことも書いておきます。
これらが理解できれば、素のJavascript(Vanilla)でフロントエンドが開発できます。
静的な「.html」拡張子のファイルを使用
可能な限り静的な「.html」拡張子のファイルにて構築します。
このことにより、SPAではないことがわかります。
さらにサーバー上では動的に作成しませんので、SSRでもありません。
SPAではないCSRと表現できそうです。
APIへの接続はasync/await型のfetch()を利用
フロントエンドフレームワークを使用する利点は、例えばアトミックデザインを始めとした開発の効率化だと思いますが、もう一つはAJAX処理の簡素化だと思います。
その手法については、以前でしたら、やれJQueryが必要だの、axiosが必要だのと言われていましたが、今はfetch()で、APIに簡単にアクセスできます。
取得したデータを後続処理に繋げたいのならば、async/await型でしょうか。
GET/POSTも可能ですし、BODYにJSONを入れてAPIを呼び出すことも出来ますし、フォームデータも可能です。
添付ファイル付きフォームデータでしたら、勝手に「multipart/form-data」になりますので、至れり尽くせりですね。
逆に考えると、共通化・部品化などがクリアできるかが、素のJavascript(Vanilla)でのフロントエンド開発の鍵になります。
CSSフレームワークは使用してよい
先の質問内容では「Node.jsを使用しない」とありましたので、Node.jsに依存しないものであれば、CSSフレームワークを使用して構わないと思います。
質問内容にJQueryの使用の可否がありませんでしたので、もし、考慮するとしたら、JQueryの使用の可否でしょうか。
今回は、JQueryは使用してOKと解釈はしていますが、JQueryに依存したコードは書かないようにします。
Webサーバーは必要
当然ではありますが、Webサーバーは必要です。
理由は簡単で、Webサーバーが無いとCookieが動作しません。また、他の環境からの実行確認ができないからです。
また、APIを通じてバックグランドでSQLでDBを操作…といったことにも使用されます。
今のところは、Webサーバーは簡易的なもので十分だと思います。
Webサーバーがあれば、とりあえず当座のAPI(JSON)モックは作成可能
気の利いたWebサーバーならば、hoge.jsonといった拡張子のファイルであれば、WebサーバーはContent-Typeをapplication/jsonにしてくれるはずです。
なので、当座の紙芝居はこれで出来るはずです。
パラメータオプション等の、APIの仕様は別途作成すると思いますが、データとして何が欲しいのアピールはできると思います。
参考：フロントエンドとバックエンドの関係について
ここまでで、簡易的な開発はできるかなと思いますが、システムの本格的な開発を行うための、前提条件である、フロントエンドとバックエンドの関係性について、もう少し深堀りしていきます。
フロントエンドフレームワークではSQLを発行できない
バックエンドのフレームワークって？…例えばRubyならばRuby on RailsやSinatraなどです。
APIって何？という方は、この記事は呼んでいないと思いますが、一般的にフロントエンドフレームワークではSQLを直接発行できません。
格的な開発にはバックエンドのフレームワークが必須
ですので、バックエンドシステムを別途開発して、バックエンド側とはAPIという手法を用いて接続し、DBアクセスを行ってもらい、結果をJSONで取得して、HTMLに反映します。
なんだか、まどろっこしいシステム開発だなあ…とは思いますが、システムも理解できて、データ管理も得意で、さらにWebデザインも簡単にできますよ…という技術者は、まず周りにいないでしょうから、こういった役割分担が大切になるのかな…と思います。
ただ、可能性としては、Webデザインもできて、Javascriptによる動きもある程度付けられる…といった方はいらっしゃると思います。
つまり…
- デザインを壊さず、制御用のclassやidやJavascriptコードを埋め込む
- フォームから入力した値をAPIに投げ、結果を受け取る
- 戻ってきたJSONから、名称や計算値を再表示したり、画面の一部を表示したり閉じたり、画面遷移したり…
- どのようなデータがバックグラウンドにあるのか？そのデータが一体どうなるのか？までは、必ずしも理解する必要はない
といったことが、フロントエンドエンジニアの主な役割だと思います。
フロントエンド開発を別途しなければいけない理由
まとめ…というほどでもありませんが、経験(？)上、フロントエンド開発を別途しなければいけない理由は…
- デザイン重視や見た目の動き重視で、バックエンド連携はあとで実装したい(デザインが壊れやすい)
- 政治的な力学(？)で、フロントエンド開発とバックエンド開発を別の会社で行うことになってしまった
- 流行に乗っておいて、技術ノウハウを溜め込みたい
- フロントエンドの方が単価が高そう
といったケースでしょうか。
APIの仕様はどちらが作る？
問題はAPIの仕様はどちらが作成するかだと思います。
- 欲しい項目の一覧、選択・照会画面の絞り込み等⇒フロントエンド側
- URLの仕様⇒バックエンド側(Restfulが実現できないバックエンドフレームワークもある)
- DBとしてセットして欲しい値⇒バックエンド側
双方が要求を投げあって、まとめていけば良いと思いますが、フロントエンド側でツールがあるのであれば、まとめるのはフロントエンド側となりそうですね。
参考：フロントエンド・バックエンドがバズワード化したパターン
参考までに、フロントエンド・バックエンドがバズワード化したパターンもあります。
割りと多いケースとしては、PHPのECパッケージのカスタマイズ等で、基幹(物流)システムにデータ連携したい場合に、(パッケージのDBとバッティングしないように)APIを活用するといったケースでしょうか。
この場合、Web側をフロントエンド、基幹システム側をバックエンドと呼んでしまうと思いますが、狭義の意味のフロントエンド・バックエンドとは異なりますよね。
ちなみに、基幹側が欲しい情報を渡す必要がありますので、APIはバックエンド側が作成します。
この場合は、ECシステム側としては、あくまでも外部データ連携という位置づけになります。
いわゆるAPIサービスと同じ位置づけです。
また、連携した情報が、どのくらい進捗しているか？(具体的には荷物がどのあたりにあるか？など)、といったAPIもありえますね。
この場合は基幹システムだけではなく、運送会社とのデータ連携なども考慮する必要がありそうです。
Vanillaでのフロントエンド構築を阻む、手間や制限について
狭義のフロントエンドシステムを振り返る
閑話休題。
狭義のフロントエンドシステムを振り返ります。
- フロントエンド側ではSQLを発行できない
- レスポンスデータの中に(SSR的な)動的データは存在しない(枠だけが存在)
- 動的データの入出力はすべてAPIで行い、セットはJavascript(fetch)で行う
- エラーチェックはAPIに任せる
- ログイン情報はCookieあるいはLocalstrageで管理(トークンを持つ)
これらについては、node.jsとかを一切利用せずに、素のJavascript(Vanilla)のみで、狭義の意味のフロントエンド開発は出来ます。
Vanillaでのフロントエンド構築を阻む、手間や制限
ただし、以下の手間あるいは制限があります。
- ヘッダー・メニューやフッターはfetch()で取得して表示
- Javascriptのインクルードはできない
- HEADタグ内はfetch()できない
- ブラウザのキャッシュを無効化できない
- キャッシュバスター(キャッシュバスティング)ができない
解決方法は？
ただ、今回の記事の目的(目標？)はVanillaのみで…なので、残念ながらReactやVue.jsなどの選択肢はありません。
(その選択肢がすでにあるのであれば、この記事にはたどり着かないかな…と思います。)
ですので、SSIあるいはバックエンドフレームワークを加味した上での開発となるでしょうね。
最終的に何を選択するか？
分かれ目となるポイントは？
分かれ目となるポイントは…
だと思います。
DBの作成もサーバーサイドフレームワークで行っているのならば、スキャフォールド(scaffold)でマスターメンテナンス的なものは簡単に作成できると思いますので、いわゆる(表に出ない)「管理画面」はサーバーサイドフレームワークで完結させ、デザイナーの絡んでいる「個性的な画面」のみHTML＋Javascript＋APIで行う…といった棲み分けを考えるのもひとつの手です。
規模感や、自分や周辺のスキルで決めても良い
小規模でまずトライしてみたい！のならば、これ以降の記事を読んでいって、Vanillaなシステムを作ってみると良いと思います。
可能であればSSIを使用してもいいでしょう。
もし、それで不満だった場合は、「個性的な画面」をReactかVueあたりで作成しても良いかなと思います。
以降の記事は「管理画面」的な画面をHTML＋Javascript＋APIで作成していきますが、もし貴方がサーバーサイドフレームワークを使いこなせていたのなら、「管理画面」は、はじめからサーバーサイドフレームワークで完結させたほうが楽でしょうね。
「個性的な画面」も、慣れていればサーバーサイドフレームワークでトライしても良いでしょうね。
(デザイナーとの連携が鍵ですが。)
といった具合に、自分の立ち位置や、スタッフの力量などで考えても良いと思います。
最後に
SSIのデメリットを紹介するサイトでは、「SSIはWebサーバーに負荷がかかるのでCSR(あるいはSSR)が良い」という意見もよく見かけますが、CSRはブラウザに負荷をかけますし、SSRはアプリケーションサーバーに負荷をかけます。
結局、どこかに負荷はかかるわけです。
CSRは動作が重く、初期表示にタイムラグが発生しやすいです。
実は、トレンドに左右され、その都度、なんらかの手法に偏るだけなのでは？とも思っています。
ただし、デザイン重視の傾向から、フロントエンドエンジニアというお仕事は、当面は安泰かもしれません。
(将来はわかりませんが。)
それでは、また。
