この記事を読んだ方がいい人

流行りのフロントエンドの用語が聞こえると萎縮してしまうバックエンドエンジニア。
ぷろぐらまーになるためにはふろんとえんどがいいとききました、な初学者の方

この記事を読まない方がいい人

フロントエンドでの実務経験がある人。

なんでフロントエンドが未知だったのか

バックエンドはこうだった

.
・
個人的に一番の壁は、処理の流れがわからなかったこと。

バックエンドの流れは

クライアントからリクエストが来る
WEBサーバで受け取る
アプリケーションに渡して処理が走る
データベースとCRUD的なやり取りをする
結果をクライアントに返す

おおまかにこんな動線になっていて、新しいシステムを扱ったとしてもだいたいこの処理してるんだなーというのが想像できました。

でもフロントエンドって画面表示する以外にどこで何のために何やってんの？が未知でした。

結果、フロントコワイフロントコワイになってる人、僕だけではないはず。

実はいっぱいパターンがある

困惑の原因はここだと思ってます。

React！とか言っても使い方がいくつかあって、それによって処理の流れが違うんです。

SPAとかCSRとか

SPA、つまりはSingle Page Application、つまりは1度アクセスするとどんな操作しても画面遷移せずに画面側でしゅいんしゅいん動くやつ。

これはCSR、つまりはClient Side Rendering、つまりはHTMLの生成やデータ取得はすべて画面側でやる！

画面側のリッチな動き！モダンな印象！いまどき！ザ、フロントエンド！

僕は個人的にこんな印象を持っています。

SSR

SSR、つまりはServer Side RenderingつまりはHTMLの生成やデータ取得は初回はサーバー側でやっちゃう。

???

なんだそれは。フロントエンドなのにサーバー側だと？

サーバー側っていうのはオレらの縄張(と書いてシマ)だぜ？

って思った方、ようこそフロントエンドの世界へ。

なんとフロントエンドのためのサーバーがあるんです。

BFF、つまりはBackend For Frontend、つまりはサーバーなんだけど、これフロントエンド用ね。っていう存在。

こいつのおかげで個人用のPCのブラウザよりもハイスペックなマシンでHTMLを高速に生成してクライアントに返却できるってことです。

SSRとかCSRの詳しい技術の違いとかは語るつもりはないのでざっくりの概念だけ理解してもらえればと思います。

ちなみにこのとき大活躍するのが Next.js です。

フロントエンドのためのサーバー処理の仕組みを支援してくれるのがこのフレームワークなので、SSRで作りたい場合にはReact.jsの頼りになる相棒という感じです。

ちなみにVue.jsを採用した場合はこの相棒は Nuxt.js というフレームワークになります。

字面としてはいろはすとボルビックくらいの違いに見えますが、実際にはコーラとジンジャーエールくらい違います。

ちなみにこの相棒、SSRじゃなきゃ不要かっていうとそういうわけでもないのでそこまで脳みそが追いついたら調べてみてください。

SSRの場合のフロントの処理

今回のプロジェクトではSSRを採用したのでSSRのざっくり説明をしていきます。

SSRのフロントエンドのコードは、

・サーバーでしか動かないコード → データ取得するコード
・サーバーと画面両方で動くコード → HTMLを生成するためのコード

が混在しています。違う環境で動くコードが一緒になってるなんてかなりカオスですね。

HTMLを生成するための画面パーツ系のコードは、アクセス時はサーバー側で動くのですが、
画面操作などをトリガーに画面要素が書き換わるタイミングでは画面側で従来のJavascript同様動作します。

具体的な動作順はNext.jsのフォルダ構成などを実際に見て、それを把握していくのが一番早いです。

やってみてわかったこと

Atomic Designの難しさ

画面の部品、フロントエンド界隈ではコンポーネントと呼ばれますが、これの実装方針が結構難しいんです。

大規模な静的ページとかを作ったことがある方はわかると思いますが、SSI(Server Side Include)を使ってファイル分割していったり、アホみたいに膨れ上がった記述量のJqueryファイルとか。

どのような設計にしていけば効率よく、理解しやすい構造でページを作成できるのか、という問題は今も健在です。

そこで、コンポーネントの粒度に着目したのがこのデザインパターンです。

要は画面パーツを粒度別に区分けしていって、

原子レベルのパーツ(ただのテキストとか) → 分子レベルのパーツ(テキストとテキストボックスの組み合わせ、とか)→...と粒度別にコンポーネントを作成していく手法です。

これは理論としてはとてもスッキリしていてさぞかし美しい構成で作れそうな気もしたのですが、実装コストがある程度あるのでなかなかしんどかったです。

粒度についてのメンバー間の認識がずれないようなコミュニケーションコストや、実用性を度外視した小さすぎる粒度のコンポーネント定義など、必ずしもこの方法が正しいわけではなさそうに思えました。

フロントエンドって仕事がいっぱい

エンジニアの化石みたいなおっさんバックエンドエンジニアの方(失礼)の中には、

フロントエンドなんて簡単だろw画面が映ればいいんだろ？

みたいなことを思ってても言わないくらいの人がいると思います。

でもフロントエンドの仕事は

・アニメーションを含む画面のスタイル調整(CSS)
・要素の構造(HTMLの階層)
・イベントドリブンな画面の変化(Javascript)
・バリデーションやデータの取得・ハンドリングなどのロジック(javascript)
・プロジェクトによってはプロダクト目線での最適な仕様やデザインの検討

と多岐にわたります。

一つの作業でも頭を切り替える必要があってバックエンドとは違った大変さがあったりします。

総括

よかったこと

初心者ながらReactを採用してよかった点は、取り巻く技術に発展性があるということです。

僕の持論では、WEB技術の世界においては人口こそ正義です。

もちろんみんなが使ってるからー、流行ってるからーだけで技術を選定していくことはリスクも大きいですが、それによって得られる情報量や連携可能な機能の多さは、生産性や選択肢に寄与します。

Reactはコンポーネントライブラリやコードの自動生成などが充実していて、それだけでもかなり人的リソースを省エネできます。

いちエンジニアとしては、フロントエンドがハイペースな発展を遂げている中で、そこのリテラシーは身につけておいて損はなさそうでした。

わるかったこと

あんまりないです。

まとめ

JavaScriptを使うかTypeScriptを使うかっていう軸もあったりします。

フロントエンドに苦手意識がある人は、ReactでもVueでも何でもいいので1つのユースケースについて突き詰めて実際に作ってみるのが良いかなと思います。

そうすると相対的に他の手法についても理解が進むようになるので、一気にハードルは下がるかと思います。

僕自身もこの間入門した最下層フロントエンドエンジニアとしてレベルアップできるよう一層頑張っていこうと思います。