0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@tanoyuusuke09

フロントエンド基本知識

0
Posted at

どうもです！
フロントエンドの座学を行いました。
方針が変わったので、この段階で投稿します。

フロントエンド辺りの基本知識

フロントエンド基本用語

HTML（マークアップ言語）

  • ファイル例：
    • index.html
    • article.html
    • login.html
    • settings.html
  • 役割
    • ページの骨組みを定義する言語
    • 画面の『ここがヘッダー』『ここが記事一覧』『ここがプレイヤー』と言った構造を表現

CSS（スタイルシート言語）

  • ファイル例：
    • styles.css
  • 役割
    • 色・余白・フォント・レイアウトなどの見た目の定義
    • 『ダークトーンのニュースサイトっぽい』『カードっぽいUI』などを表現

Javascript（スクリプト言語）

  • ファイル例：
    • main.js（ページごとの初期化）
    • auth.js（ログイン状態管理 ※今はモック）
    • apiClient.js（API呼び出し＋モック）
  • 役割
    • 『ページ表示後の動き』を担当するフロント側のプログラミング言語
    • 例
      • APIから記事一覧を取得してカードを生成
      • URLの?id=を読んで該当記事の詳細を表示
      • ログイン・ログアウト状態でナビゲーションを出し分ける
      • 設定ページでチェックボックスON/OFF→設定保存

React（JavaScriptのUIライブラリ）

  • 役割
    • 画面を『コンポーネント』と言う部品に分けて組み立てるためのライブラリ
    • HTMLをそのままベタ書きするのではなく、再利用出来る部品として定義する

Next.js

  • Next.js = React 用のフルスタックフレームワーク
  • React単体は画面をコンポーネントで作るライブラリ
    • それだと以下を自前で整えないといけない
      • ルーティング（URLごとの画面切り替え）
      • SSR / SSG（サーバーサイドレンダリング / 静的サイト生成）
      • APIエンドポイント
      • 画像最適化
    • Next.jsは、Reactを使ってSSR/SSG/ルーティング/APIをまとめて面倒見てくれるフレームワーク

TypeScript（型付きJavaScript）

  • 役割
    • JavaScriptに「型」をつけた言語
    • 書いたものはビルド時に普通のJavaScriptに変換される
    • APIのレスポンスやアプリ内のデータ構造を型で表現してバグを事前に防ぐ

Vite（ビルドツール & 開発サーバ）

  • 役割
    • 開発中
      • npm run dev→ローカル開発サーバを起動
      • ファイル保存→ブラウザが即リロード/部分更新（HMR）
      • TypeScriptやJSXをその場でいい感じに変換してくれる
    • 本番用
      • npm run build→ソースコードをS3に置ける静的ファイルに変換
      • TypeScript→JavaScript
      • JSX→JavaScript
      • モジュールをバンドル
      • コードを圧縮・最適化

ライブラリ

  • とは
    • ライブラリ＝再利用できるコードのまとまり
    • 自分で全部0から書かなくていいように、『よくある処理』をまとめてくれたもの

ビルドされた成果物

  • S3にデプロイするディレクトリはビルドされた成果物のディレクトリ
  • ビルドする前のソースコードは別ディレクトリとなる

SSG（Static Site Generation）

  • SSG = Static Site Generation（静的サイト生成）
    • 本番でリクエストが来てからHTMLを作るのではなく、デプロイ前のビルド段階であらかじめHTMLファイルを全部作っておく方式
  • 他との違い
    • CSR（SPA）
      • HTMLはほぼ空
      • ブラウザでJSが動いてから中身が作られる
    • SSR
      • リクエストごとに、サーバーでHTMLを組み立てる
    • SSG
      • npm run buildしたときに全ページのHTMLを事前に生成してします
      • 本番はS3から出来上がったHTMLを返すだけ
  • SSGの特徴
    • 本番は静的HTMLを返すだけなので爆速＆安定
    • SEOにも有利
    • ページ数が超多いorリアルタイム更新が激しいとしんどい
    • 記事を更新したら『再ビルド・再デプロイ』が必要

SPA（CSR）＋ S3 + CloudFront

  • SPA = Single Page Application
  • CSR = Client-Side Rendering（クライアントサイドレンダリング）
    • 最初に1枚のHTMLとJSを読み込んで、そのあとはページ全体の再読み込みなしで中身だけ入れ替えるアプリ型のwebサイト
  • Reactをビルドして静的にファイルにする
    • それをS3+CloudFrontに載せて配信するだけ

SSR（Next.js など）＋ Node/ECS

  • SSR = Server-Side Rendering = サーバーサイドレンダリング
    • ページのHTMLをサーバー側で毎回組み立てからブラウザに渡す方式

First Contentful Paint（FCP）

  • FCPはwebパフォーマンス指標ののひとつ
    • ユーザーが何か意味のあるコンテンツ（文字や画像）を最初に目で見れられるまでの時間
  • 例
    • 画面が真っ白→まだFCP前
    • タイトル・テキスト・画像などがポンと出る→ここでFCP
  • ユーザー視点
    • クリックしてから何か読めるものが出るまで何秒かかったか？

LCP（Largest Contentful Paint）

  • LCP = Largest Contentful Paint
    • 画面の中で一番大きな意味のあるコンテンツ（大きな画像・大きな見出し）が表示されるまでの時間
  • ページを開いたときの流れ
      1. 背景だけチラッと出る（FCPに近い）
      2. ヘッダーが出る
      3. 大きなタイトル・メイン画像・カード一覧など、そのページの主役が出る
    • この主役が出てくる瞬間の時間を計測したのがLCP。

Time To First Byte（TTFB）

  • ブラウザがリクエストを送ってから、最初の1バイトのレスポンスが返ってくるまでの時間
  • 計測の流れ
      1. ユーザーがページを開く（URLにアクセス）
      2. ブラウザがサーバーにHTTPリクエストを送る
      3. サーバー側で
        • ネットワーク・ルーティング
        • もろもろの処理（SSRならレンダリング処理も含む）
      4. その結果最初のレスポンスデータ（1バイト目）が返ってくる瞬間までの時間がTTFB
    • SSRだと、サーバー側でHTML生成してから返すのでTTFBが少し長くなることがある
    • 静的ホスティングだと、計算ほぼゼロでファイルを返すだけなので、TTFB自体は早くなりやすい

Time To Interactive（TTI）

  • ページがちゃんと触れるようになるまでの時間
  • 単に見た目が表示されるだけじゃなくて、ユーザーが操作してもちゃんとレスポンスが返ってくる状態になった時間をさす
  • 流れ
    • HTMLが返ってくる
    • 画面の見た目（テキストや画像）は先に出る（これがFCPやLCPに関係）
    • JSファイルをダウンロード・解析・実行
    • イベントハンドラ（クリック・入力など）が登録される
    • 『もう操作してもOKな状態になった！』→ここがTTI

ECS（Amazon Elastic Container Service）

  • Docerコンテナを大量に安定して動かすためのAWSのサービス
  • コンテナ= 『アプリ本体＋そのアプリに必要な環境一式』を1つの箱にしたもの
    • 例：Nginx + Reactビルド成果物
    • 例：Go のバイナリ + ライブラリ
  • ECSはそのコンテナを管理してくれるオーケストレーションサービス
    • 何台動かすのか
    • どのインスタンスで動かすのか
    • 落ちたら再起動するか

Dockerコンテナの役割・必要性

  • イメージ
    • アプリ本体と、そのアプリに必要な環境をひとまとめにした箱
  • 普通は環境に差が出る
    • 自分のPC：Node 20/Linux/このバージョンのライブラリ・・・
    • 本番サーバ：Node 18/別のLinux/微妙に違うライブラリ・・・
  • Dockerコンテナ
    • OSのレイヤーの上に1つのアプリ用のミニ環境を作る
    • その中に以下を全部入れると、どこに持って行っても同じ動きをする箱にする
      • NodeやGoNginx
      • 必要なライブラリ
      • アプリ本体
  • ざっくりの役割として
    • 動作環境ごとアプリをパッケージ化するツールで、それを大量に動かすのが、ECSやEKS。
  • OSレベルではLinux同士ならほぼ変わらない？？？

OS・コンテナ・クラウドなどの関係

  • OS
    • macOS,Linux,Windows
      • ハードウェアを管理する土台
      • アプリケーション（ブラウザ、Node,js、Docker）を動かす土台
  • コンテナ
    • Dockerコンテナ、Kubernetesのpod、ECSのタスク内コンテナ
      • OSの上にアプリ専用のミニ環境を作る
  • 実行環境
    • プログラムが実際に動く場所・状態
    • OSだけでなく、言語ランタイム、依存ライブラリ、環境変数、ファイル配置、ネットワーク設定など全部を含むことが多い
  • ビルドツール
    • ソースコードから配布・実行できる形を作る道具
  • 言語
    • ソースコードを書くためのルール
    • 言語の種類によって実行に必要なものが変わる
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?