アーキテクチャ

頻繁に聞こえてくるけどわからんと完全に会話に置いていかれる、略語ラッシュやめてくれ〜

SPA

🤔 会話の流れとふいんきだけで理解している

• １ページだけの Web ページで提供されるもの ( Single Page Application )
• 最初に空の HTML を取得し、クライアント側がコンテンツを JavaScript で取得して描画する
• 差分取得になるため通信量が減り、読み込みが速くなる
• ページ遷移がなくなりアプリと似た感覚で使える

😗 概ねイメージ通り

CSR

🤔 聞いたこともない

• クライアントサイドレンダリング ( Client Side Rendering )

😗 ほぼほぼ、イコール SPA ってことでいいのかな...??

SSR

🤔 聞いたことない、ガチャ？

• サーバサイドレンダリング ( Server Side Rendering )
• SPA は
  • 最初の HTML が空なので SEO や OGP に対応しづらい
  • クライアントのスペックに依存しやすい
  • 画面遷移でリクエストが発生しないが、巨大になると初回通信の負荷が上がる
• それと比べて SSR は
  • サーバでレンダリングした HTML を返すので SEO や OGP 対応しやすい
  • サーバでレンダリングすれば、クライアントのスペックが低くても問題になりにくい
  • 初回通信時はレンダリングした HTML を返し、以降は SPA を用いれば高速化できる

😗 SPA も用いる点が従来の MVC + テンプレートエンジンの構成とは区別されている、らしい...??

SSG

🤔 これも聞いたことない

• 静的サイト生成 ( Static Site Generation )
• SSR は
  • リクエストごとにサーバがレンダリングをするのでレスポンスが遅い
• それと比べて SSG は
  • リクエスト時ではなくビルド時にレンダリングをする
  • 静的ファイルの配布になるので高速だが、当然動的に内容を変更できない

😗 SNS や動きの多いブログサイトなどには使えなそうだけど、うまくはまれば速そう

ISR

🤔 これも聞いたことない、もう 3 文字系は勘弁してください...

• 段階静的サイト生成 ( Incremental Static Regeneration )
• SSG では
  • 常にコンテンツが更新されるようなサービスの実現は難しい
• それと比べて ISR は
  • 事前にレンダリングした情報を返しつつ、内容を更新するためのレンダリングもする
  • SSG + SSR のような方式

😗 いつレンダリングするかなど、聞いただけで難しい感じしかしない

BFF

🤔 Back to the Future... ではないか

• Backends For Frontends は構成例の名前
• フロントエンド専用のバックエンドサーバで、API コールや HTML 生成を行うサーバを設ける
• 従来サーバが行っていた責務をバックエンド専用とフロントエンド専用に分ける
  • e.g. DB 検索やデータの更新など ( バックエンド )
  • e.g. ページの構築やユーザ入力の受付 ( フロントエンド )

生まれた背景

1990 年くらいは HTML が基本で、サーバはモノシリックだった

2000 年くらいから Ajax 通信が広まり、サーバはデータ送受信の役割が多くなった

さらにモバイルアプリなどが増え、サーバは特定のことに特化した API にわかれていった

クライアントごとに UI などの差分が出て来て、責務特化 API では対応しきれなくなった
なので間に PC 用 BFF やモバイル用 BFF などを置くようになった

😗 あー、苦しいのわかる、BFF もイメージ湧く

BLoC

🤔 Block と混じって検索しづらい

• Business Logic Components とは UI から分離してロジックを実装する実装パターン
• Google Flutter チームからも推奨されている
• 入力内容の計算などのロジックと、表示や整形などの処理を分離する考え方
• プラットフォームに依存しないようにする

😗 なんだか関数的だな、イメージしやすい

Micro Frontend

🤔 コンポーネントを分けましょうみたいなはなし...??

• 単体で実行可能な、ページから切り離された特定の UI 領域のこと
• 次の利点がある
  • ほかの部品に依存しないので技術スタックの融通が効きやすい
  • 独立修正、独立デプロイがしやすい
  • 小規模になるのでコードベースがシンプルになる
  • 自立チームと合う
• 次のような機能を提供し、アプリケーションに統合される
  • ヘッダーなどのレンダリング
  • 認証などの横断機能
• バックエンド通信のパターンとして BFF を用いたりする

😗 1 サービスにおけるファイル分割というより、UI 部品でマイクロサービスみたいな感じかな...??

Flux

🤔 たまに聞こえてくる、気がする...

• Facebook が提唱しているアプリケーションのデータフロー管理のアーキテクチャパターン
• View, Action, Dispatcher, Store の 4 要素で構成する
• 単方向へデータが流れることで追いやすくする
• AngularJS の双方向データフローと対照的な React の単方向データフローをサポートするため
• 一般的な MVC アーキテクチャの代替となるもの
• オブザーバパターンの亜種と考えることができる

😗 実践予定はないので図は保留、データフローのアーキテクチャパターンだという点だけ抑えた

まとめ

ここは本当に会話についていけなくて辛いところだった

何の略か理解してしまえば、個々の概要自体はそう難しいものではない気がする
今整理できてよかった

実践したら絶対難しいことがいっぱいあるはずなので、これ以上はそのときに