Front-End Study #1「Cloud Native時代のフロントエンド」での学習事項

はじめに

本記事は以下の勉強会での学習事項をまとめることを目的としています。
参加した勉強会はこちらを参照ください。
上記の勉強会の基調講演、セッション1、セッション2について、学習事項をまとめます。

基調講演：「フロントエンド領域」を再定義する

ここ10年の振り返り

• IE Firstが終わり、Chromeがシェアトップ。IEに合わせるではなく、足を引っ張るならサポートを切る。
• 動くテンプレートが当たり前に。仮想DOMを使う技術やフレームワークが豊富に。
• JavaScriptはウェブのCO2。使いすぎると悪影響が出る。
• Deno：npmパッケージを使わずにURLパスでライブラリ参照。
• Rome：TypeScript First。外部ライブラリを使わずに自前ライブラリで動作。
• Blitz：今までのベストプラクティスを詰め合わせ。
• prisma2：TSフレンドリーでクエリに型付けできる。Blitzを含めたライブラリから利用される。
• JavaScriptは古く、モダンJavaScript=TypeScriptとなっている。いいコードは型付けという思想。

Next.jsから得たベストプラクティス

• Next.js：静的サイトやサーバー上で動作するアプリケーションを実現可能。
• 静的サイトジェネレータを動的に実行する形態。
• Next.jsが実現したこと：SPA/SSRの複雑な仕組みを隠ぺい。
• SSRは多くのユースケースで不要。

フロントエンド領域の変化

• Blitzのフルスタックでは、フロントエンドとバックエンドの境界がほぼなく全てがnode.jsにのっかる。
• 現実的に、フロントエンドはJS以外は厳しい状況。
• ただC#のBlazorやRustのYewはNode.jsから脱却できる可能性を秘めている。
• 宣言的UI+Next.jsをWebAssemblyで実装。
• 多言語でJSに対応する仕組みを作るのがはやり。
• TypeScript + 部分的にRustが当面はベスト。
• CDN Edge Worker：Edgeに合わせて最適化されており、Lambda@Edgeよりデプロイが高速。
  • 自由度の高いキャッシュコントロールが可能。

将来の展望

• TS + Next.js + RustがWebのベストプラクティス。
• 2020年代にはFullstack Node.jsがRailsに置き換わる。
• 課題はNode.jsにはRailsのような学習コンテンツが存在しないこと。

質疑応答

• Rustは高速なので、CPU負荷が高くなる箇所が徐々に置き換えられていくだろうという予想。
• フロントエンドやWebアプリケーション開発するなら今後はRustは必須の流れになりそう。

セッション1：フロントエンド開発者も知っておきたいAWS Lambdaとサーバーレス

サーバーレスとは

• サーバサイドで語られることが多い。フロントエンド開発者が全てを自分で作るためにサーバレスを学ぶという比率は低い。
• サーバの準備が必要ない。セキュリティやネットワークもサービス側がケアする。
• SPA + API、SSR + API、SSG + APIがWebアプリケーションの構成のほとんどを占める。
• GraphQL：APIの実装方式の一つ。
  • AWS AppSync：GraphQLのエンドポイントを公開できるサービス。
  • AWS Amplify：フロントエンド開発者向けツールセット。AppSyncを使う場合におすすめ
• REST
  • Amazon API Gateway：HTTPのエンドポイントを公開できるサービス。
  • AWS Lambda：Funstion As A Service。ランタイムのセットアップ不要。多くのAWSサービスと連携できる。
  • DataStoreは目的に応じて使い分けることを推奨。

SPA with Serverless

• Amazon S3とAmazon CloudFrontを使ってホスティング。
• Amplify CLIだとより楽にパブリッシュ可能。

SSR with Serverless

• SSRはサーバーサイドでレンダリングするのでサーバーが必要。
• インフラ的には、CPC負荷が高くなり、さばけるリクエスト量が制限されるといった課題が生じる。
• AWS LambdaとSSRは相性がよい。
  • 関数の裏側はコンテナが立ち上がる。1リクエストは同時に1コンテナでしか処理されない。
  • リクエストが増えても、水平にスケールするため、リクエスト集中でCPU負荷が高まっても、クライアントにレスポンスが返せなくなることがない。
• How
  • Next.js/Nuxt.jsを使う。
  • Expressで動かせるようにする。Expressで作ったアプリをLambdaで動かす。
  • 全てが同じ関数でデプロイされてしまう。無駄が生じてしまう。
• 静的アセットはS3 + CloudFrontで配信する。

SSG with Serverless

• 基本的にSSGの配信はSPAと同じ考え方でいい。

まとめ

• API GatewayとLambdaはすでに事例も多く、参考ドキュメントも多い。
• サーバレスも現時点では技術的に過渡期にあたるので、最新技術は要チェック。

質疑応答

• サーバレスにおける、リクエスト量に対する負荷はアプリケーションに大きく依存する。
• したがって、実際に計測する必要がある。

セッション2：STUDIOのデザインツールとホスティングの仕組み

• STUDIO
  • ノーコードで静的サイトを作成し、パブリッシュできるサービス。
  • C#におけるWindow.FormsのようにコントロールをGUIで配置できる。ライブプレビュー機能で編集内容が即座に確認可能。
• 登壇者がSTUDIOを開発したきっかけ
  • Vue.jsとFirebaseを使って遊んでいたところ、組み合わせることでWebページエディタが実現できることに気づいたため。
• STUDIOのストラクチャ
  • 公開するサイトはSSRで実現している。
  • Vue.jsとFirebaseとの親和性を考慮して、Google Cloud上で実現。
• 公開サイト公開のための工夫
  • 画像の最適化。
  • static jsonを使っての性能改善。ページのheadのみをSSRする。

質疑応答

• OpenGraphProtocolはスループットに影響を与える可能性が高い。