Next.jsの記事でReactはSPAとして単一のJavaScriptを生成する、という話をしました。

今回は改めてSPAとSSR、SSGのしくみや違いについてまとめてみようと思います。

# レンダリングおさらい
[ブラウザレンダリングのしくみ](https://next-contentful-vert.vercel.app/blog/rendering)の記事で簡単にまとめていますが、まずレンダリングのおさらいをしてみます。

レンダリングとは、サーバーから受け取ったHTML,CSS,JavaScriptをブラウザに表示させる一連の流れのことをいいます。

簡単にまとめると、

1.HTML、CSS、JavaScriptの順にParsing（ブラウザが理解できる形式に変換）

2.レンダーツリー（HTMLのDOM、CSSのCSSOM）と呼ばれるツリーオブジェクトを生成

3.画面にレイアウト

4.描画

の流れです。

# SPA(Single Page Application)とは
**SPAとは、名前のとおりページ遷移を行わず、１つのページでコンテンツを切り替えるアプリケーションのことをいいます。**

それに対して、**各ページごとにHTMLファイルが存在する従来のしくみをMPA(Multiple Page Application)といいます。**

MPAでは、クライアント側からのリクエストごとにサーバーがHTMLファイルを返し、描画（レンダリング）します。

### SPAのしくみ
SPAでは、クライアント側からの初回リクエストのみ、サーバーがほぼ空のHTMLファイルとすべてのファイルを返し、クライアント側で描画します。

具体的な流れは下記のとおりです。

1. アプリをビルドしてホスティングサーバーにあげる
2. 初回はクライアントからホスティングサーバーにリクエストし、サーバーはビルド済みのファイル（ほぼ空のHTMLファイルとすべてのファイル）を返す
3. 2回目以降は、クライアントからAPIサーバーに差分のみリクエスト
4. APIサーバーからjsonやXML形式のファイルを返す
5. クライアントが差分をレンダリング

**クライアントでレンダリングを行うため、SPAのしくみは、CSR(Client Side Rendering)ともいいます。**

### SPAのメリット
- ページ遷移が早い（サーバーとの通信を最小限にすることでUI/UX向上）
- シンプルな構成（単一のHTMLファイルとJavaScriptで構成される）

### SPAのデメリット
- 初期表示は遅い
- SEOに不利な可能性（HTMLはほぼ空で、GoogleクローラはJavaScript実行まで待たないのでコンテンツが認識できないと言われていましたが、現在はJavaScript実行後に認識されるので改善されつつあります）
- 動的なOGPは対応できない

# SSR(Server Side Rendering)
**SSRとは、サーバーでレンダリングを行ってHTMLを生成し、クライアント側では描写(Painting)のみを行う技術です。**

SPAのデメリットであった初期表示の遅さやSEO問題を解消することができます。

### SSRのしくみ
SSRでは、クライアント側からの初回リクエスト時にサーバーでHTMLを生成してクライアントに返し、クライアントは返されたHTMLを表示させます。

具体的な流れは下記のとおりです。

1. クライアントからNode.jsサーバーにリクエスト
2. Node.jsサーバーからAPIサーバーにアクセス
3. APIサーバーからNode.jsサーバーへ初回データを返す
4. Node.jsサーバーでレンダリング、クライアントへレンダリングされたファイルを返す
5. クライアントで表示
6. 2回目以降のリクエストは、SPAと同様に差分のデータのみAPIサーバーへリクエストしてクライアントでレンダリングを行う

### SSRのメリット
- SPAの初期表示問題解消
- SPAのSEO問題解消

### SSRのデメリット
- Node.jsサーバー実行環境が必要（Next.jsやNuxt.jsのフレームワーク利用可能）
- サーバーの負荷増加

# SSG(Static Site Generation)
訳すと静的サイト生成とあるように、SSGはアプリのビルド時にAPIからデータを取得し、静的なHTMLファイルを生成するしくみです。

### SSGのしくみ
**SSGでは、ビルド時にHTMLファイルを生成し、クライアントからリクエストがあったら、サーバーは生成済みのファイルを返します。**

具体的には

1. アプリのビルド時にNode.jsサーバーからAPIサーバーへアクセス、データ返却されたらさーばーでレンダリングしてHTMLファイル作成
2. クライアントからNode.jsサーバーにリクエスト
3. Node.jsはビルド時に生成したファイルを返す
4. クライアントで表示

**SSGはリクエストより前にレンダリングを行って静的ファイルを生成しておくので、プリレンダリングともいいます。**

### SSGのメリット
- 表示速度が早い（事前にレンダリング済みなので）
- SEO向上

### SSGのデメリット
- 更新頻度が高いサイトには不向き（更新のたびにビルドしなければ変更が反映されない）
- ページ数が多いとビルドに時間がかかる

# まとめ
開発するアプリケーションによってSPA、SSR、SSGのどれを選択するべきか、最適な選択ができるようになりたいですね。


SPASSRSSG

SPAとSSR、SSGについて

Next.jsまとめシリーズ。

アウトプットとしてまとめていきます。

# 環境変数とは
ここでの環境変数とは、アプリケーション内で利用できる変数のこと。

例えばAPIによって外部アプリケーションからデータ取得する際に必要になるAPIキーなど、環境変数として定義します。

# Next.jsがサポートする環境
Next.jsでは、

- development
- production
- test

の3つの環境をサポートしています。

# ファイルの種類

- **.env** : すべての環境に対する環境変数（デフォルト値）

- **.env.local**: リポジトリに含めてはいけない環境変数を書く（前述のAPIキーなど外部に露出したら困る秘密情報）。すべての環境の環境変数を上書きする。

- **.env.[environment]** : 特定の環境に対する環境変数（デフォルト値）。**.env.development** など

- **.env.[environment].local** : 特定環境のローカル用環境変数。特定の環境に対する環境変数を上書き。**.env.development.local** など

## .env.[environment]と.env.[environment].local について
.env.developmentと.env.development.localは、**next dev**コマンド実行時に使用されます。

.env.productionと.env.production.localは、**next build**と**next start**コマンド実行時に使用されます。

.env.testと.env.test.localは、テスト目的に特定の環境変数を設定する必要がある場合に作成します。また、テスト環境においては**.env.local**ファイルはロードされないため注意が必要です。

# 各ファイルの優先順位

```javascript
.env.[environment].local > .env.local  > .env.[environment] > .env
```

の順で優先されます。

# 環境変数の設定方法と参照方法
## 設定方法
**ルートに.env.localファイルを作成し、変数を定義します。**

```javascript
API_KEY='my-secret-api-key'
```

## 参照方法
下記のように、**process.env.XXXXX**と書くことで参照することができます。

```javascript:index.jsx
export async function getStaticProps() {
  const db = await myDB(process.env.API_KEY)
  // ...
}

```

# クライアント側で使いたいとき
クライアント側で使う環境変数には**NEXT_PUBLIC_**　をつけて定義することで、ブラウザに送信されるJavaScript内に環境変数の値がインライン化され、クライアント側で使用できます。

```javascript
NEXT_PUBLIC_ID=advresgfsl
```

```javascript:index.jsx
export default function Page(){
const { NEXT_PUBLIC_ID } = process.env
console.log(NEXT_PUBLIC_ID) // advresgfsl
// ...
```

当然ですが、公開したくない秘密情報については**NEXT_PUBLIC_**　をつけず定義します。

# .gitignoreへ追加
**.env.lovalと.env.[environment].localについては秘密情報を定義するので、.gitignoreファイルに追加しておきます。**

公式ドキュメントによると、その他.envファイルについてはリポジトリに含めてデフォルト値設定のため使用することが推奨されています。
>Note: .env, .env.development, and .env.production files should be included in your repository as they define defaults. .env*.local should be added to .gitignore, as those files are intended to be ignored. .env.local is where secrets can be stored.
[公式Docより](https://nextjs.org/docs/basic-features/environment-variables#default-environment-variables)


Next.jsの環境変数はどう設定するか

next_arrow

Next.js環境変数の取り扱いについて

前回、NextAuth.jsでパスワードレス認証が簡単に実装できる！という記事を書きました。

今回はその第二弾として、データベース連携についてまとめていきたいと思います。

# 👑ゴール：認証したユーザーをデータベースに保存

今回のゴールは、前回実装したGithubログインしたユーザーの情報をデータベースに保存することです。前回に引き続き、NextAuth.jsを使用して実装します。

# データベースとの連携

前回の記事でも書きましたが、NextAuth.jsではMySQL、MariaDB、PostgreSQL / CockroachDB等のデータベース連携がサポートされています。

今回の例ではPostgreSQLを使用します。また、ORMとしてPrismaを使用します。

# ORM(Object-relational mapping)とは

[Prisma](https://www.prisma.io/)は、オープンソースのORMです。

**ORM**とは、簡単に言うと**アプリケーション（オブジェクト指向プログラミング言語）とデータベース（リレーショナルデータベース）の間に入ってデータを変換し繋いでくれるもの**です。

Prismaによって、データベース言語（SQL）を書くことなく、Node上のアプリケーションで直接データベースに接続し、クエリ発行が可能になります。

今回の例でいうと、直接会話すると言葉が通じないところがあるNext.js（で作ったアプリケーション）とPostgreSQL（データベース管理システム）の間に入って両者のやりとりがスムーズになるよういい具合に通訳して仲を取り持ってくれる仲人さんがORMということですね。

NextAuth.jsもPrismaを利用したデータベース連携をサポートしており、サンプルコードも掲載されています。

# Prismaの構造

実装の前にPrismaの構造を簡単にご紹介します。

### Prisma Model
アプリケーションで使用するモデルを表現する。
モデル内でテーブルやカラムの定義を行う。
また、Prisma Clientでクエリを発行するために必要となる。

### Prisma schema
メインとなる設定ファイル。
データベースクライアントやマイグレーションファイルの生成を行う。

### Prisma Client
データベースクライアント。
Prisma Modelでの型情報を使用して、クエリーの結果は型安全になる。

### Prisma Migrate
Prisma Schemaの情報をベースにマイグレーション周りの処理が可能になる。

### Prisma Studio
データベース上のデータを閲覧・編集するGUI。

> ORM初心者にとってありがたいのはPrisma Studioの存在。詳しくは後述しますが、データをブラウザで閲覧・操作できるのでわかりやすい！Prismaは開発者の生産性向上を目的に開発されているそうです。

# 実装

## １．Prismaインストール

```node
npm install prisma --save-dev
npm install @prisma/client
```

インストールしたら、

```node
npx prisma init
```

コマンド実行することで、rootディレクトリにprismaディレクトリと.envファイルが作成されます。

## ２．Prisma schemaファイルの作成

NextAuth.jsで認証したユーザー情報を保存するためのスキーマファイルを作成します。公式ドキュメントにスキーマファイルのサンプルがありますので、今回はこちらを利用します。

```javascript
generator client {
 provider = "prisma-client-js"
}

datasource db {
 provider = "sqlite"
 url      = "file:./dev.db"
}

model Account {
 id                 Int       @default(autoincrement()) @id
 compoundId         String    @unique @map(name: "compound_id")
 userId             Int       @map(name: "user_id")
 providerType       String    @map(name: "provider_type")
 providerId         String    @map(name: "provider_id")
 providerAccountId  String    @map(name: "provider_account_id")
 refreshToken       String?   @map(name: "refresh_token")
 accessToken        String?   @map(name: "access_token")
 accessTokenExpires DateTime? @map(name: "access_token_expires")
 createdAt          DateTime  @default(now()) @map(name: "created_at")
 updatedAt          DateTime  @default(now()) @map(name: "updated_at")

 @@index([providerAccountId], name: "providerAccountId")
 @@index([providerId], name: "providerId")
 @@index([userId], name: "userId")

 @@map(name: "accounts")
}

model Session {
 id           Int      @default(autoincrement()) @id
 userId       Int      @map(name: "user_id")
 expires      DateTime
 sessionToken String   @unique @map(name: "session_token")
 accessToken  String   @unique @map(name: "access_token")
 createdAt    DateTime @default(now()) @map(name: "created_at")
 updatedAt    DateTime @default(now()) @map(name: "updated_at")

 @@map(name: "sessions")
}

model User {
 id            Int       @default(autoincrement()) @id
 name          String?
 email         String?   @unique
 emailVerified DateTime? @map(name: "email_verified")
 image         String?
 createdAt     DateTime  @default(now()) @map(name: "created_at")
 updatedAt     DateTime  @default(now()) @map(name: "updated_at")

 @@map(name: "users")
}

model VerificationRequest {
 id         Int      @default(autoincrement()) @id
 identifier String
 token      String   @unique
 expires    DateTime
 createdAt  DateTime  @default(now()) @map(name: "created_at")
 updatedAt  DateTime  @default(now()) @map(name: "updated_at")

 @@map(name: "verification_requests")
}
```

## ３．Prisma Clientの生成とマイグレーション

schemaファイルを作成したら、

```node
npx prisma generate
```

コマンドを実行します。

これにより下記のとおりPrisma Clientコードがnode_modules/@prisma/clientに生成され、ここからimportすることでPrisma Clientインスタンスを作成することができます。

```node
✔ Generated Prisma Client (2.23.0) to ./node_modules/@prisma/client in 103ms
You can now start using Prisma Client in your code. Reference: https://pris.ly/d/client
```

```javascript
import { PrismaClient } from '@prisma/client'
const prisma = new PrismaClient()
```

また、schemaファイルをもとにmigrateを行います。（開発環境のためmigrate devコマンドを使用します。）

```node
npx prisma migrate dev --name init
```

prismaディレクトリ内にmigrationsディレクトリが生成され、migrateの履歴を見ることができます。

## ４．[...nextauth].jsファイルにAdapterの記述追加

```javascript:[...nextauth].js
import NextAuth from "next-auth"
import Providers from "next-auth/providers"
import Adapters from "next-auth/adapters"
import { PrismaClient } from "@prisma/client"

const prisma = new PrismaClient()

export default NextAuth({
 providers: [
   Providers.GitHub({
     clientId: process.env.GITHUB_ID,
     clientSecret: process.env.GITHUB_SECRET,
   }),
 ],
 adapter: Adapters.Prisma.Adapter({ prisma }), // 追加
})
```

これにより、NextAuth.js が prisma と連携して、サインインなどのアクションがあった場合、prisma 経由でユーザー情報をデータベースに保存することができます。

## ５．Prisma studioでデータ生成の確認

ここまででNextAuth.jsとPrismaによるデータベース連携の実装は完了です。

ログインしたユーザーがデータベースに保存されたか確認するために、Prismaの構造で紹介したPrisma Studioを起動します。

```node
npx prisma studio
```

ブラウザで確認すると、マイグレーションしたモデルが表示されています。
![prisma1](//images.ctfassets.net/q5y6t65v3t0p/2atPuIl1Jm3wRK1IAc5GFJ/350825c751d0095f8ed5d27c7969c940/picture_pc_96bb279f243ce58ce3784e17532c6f18.png)

> schema.prismaファイルに記載したとおり、Account,Session,User,VerificationRequestモデルが生成できていることがわかります！データベースの中身をブラウザで確認できるPrisma Studio、ありがたいです・・・

ここでブラウザで開発モードを立ち上げ、前回実装したGithubログインをしてみます。
![prisma2](//images.ctfassets.net/q5y6t65v3t0p/3uAYs8ifiNrPlvo0sS57j2/6717ffa2c050fce26af05440231f3643/picture_pc_38fae73468ca3f3ef2626efe48998f6e.png)

> NextAuth.jsのsigninメソッドを使用することで上記のように自動的に生成されるシンプルなログイン画面が表示されます。こちらは自分で作成した別のログインページに置き換えることができます。
![prisma3](//images.ctfassets.net/q5y6t65v3t0p/6QLx6FI8Hp4qkyCvvHJX8Q/c34cac19acaef192208476dc988047d9/picture_pc_e0bd57f1408436cc4a0a5cd0ea6913f3.png)

サインイン完了！Prisma Studioを確認してみると・・・・
![prisma4](//images.ctfassets.net/q5y6t65v3t0p/11EtkLvHAIX41Gnta3nKlD/72d1783fc8de3d5eb7a900c11b23ba8e/picture_pc_6d1066072f044e430eccacc4edd44399.png)

データが追加されています！

ちなみに、前回認証済みのユーザーについてはsessionによって挙動をコントロールすることができるという話をしました。

```javascript:index.jsx
export default function Home() {
 const [session] = useSession();

 return (
   <>
     {!session && (
       <>
         サインインしてください。 <br />
         <button onClick={() => signIn()}>Sign in</button>
       </>
     )}
     {session && (
       <>
         サインイン完了。 email: {session.user.name} <br />
         <button onClick={() => signOut()}>Sign out</button>
       </>
     )}
   </>
 );
}
```

認証済み（sessionがある）かどうかでSign inボタンとSign outボタンの表示/非表示を切り替えています。

sessionにはユーザー情報やアクセストークンが入っています。

認証済みユーザーの情報については、session.userで取得することができますが、ここで取得できる情報はProviderの情報（今回の例だとmail,name,image）になるので、追加でidなどデータベースの情報を取得したい場合は[...nextauth].jsファイルのoptionにcallbacksとして追記することで取得できます。

```javascript:[...nextauth].js
const options = {
 providers: [
   Providers.GitHub({
     clientId: process.env.GITHUB_ID || "",
     clientSecret: process.env.GITHUB_SECRET || "",
   }),
 ],
 adapter: Adapters.Prisma.Adapter({ prisma }),
 callbacks: { // 追加
   session: async (session, user) => {　
     session.user.id = user.id;
     return Promise.resolve(session);
   },
 },
};
```

> callbacksはこの他にもサインイン実行時に非同期で実行される処理やリダイレクト処理、JSON Web Token生成（更新）時の処理を行うことができます。（参考：[公式Doc](https://next-auth.js.org/configuration/callbacks)）

# まとめ

業務を通してPrismaを初めて使用しましたが、ORMとは何かというところも含めて勉強になりました。認証機能にも様々な実装パターンがあり、Prismaのように新しいサービスも生まれるので、日々勉強ですね。

では、また次回です！

prisma

NextAuth.jsで認証機能実装その２【データベース連携】

以前、Next.jsで開発を進める中で学んだIncremental Static Regenerationについて投稿しました。

今回は上記記事の続きとして、**Next.jsでの認証機能実装**についてまとめていこうと思います。

# 認証機能実装について

会員登録制のアプリケーションで必須となる認証機能。

認証機能はユーザーから提供された名前、メールアドレス、パスワードなどの資格情報を検証し、ユーザーが本人であるかを確認する重要で機密性の高い機能です。

これまで、個人開発や仮実装のアプリケーションでは[Firebase](https://firebase.google.com/)を利用したメールアドレス、パスワードによる認証機能を実装していました。

Firebaseでももちろん実装できますが、Next.jsはFirebase以外にも複数の認証パターンをサポートしています。

まずNext.jsでの認証機能実装について、２つのパターンをみていきます。

# Next.jsでの認証機能実装パターン

## 静的に生成されたページの認証

Next.jsはgetServerSidePropsの記載がない限りビルド時にページを静的生成（SSG：Static Site Generation）します。

ビルド時にはユーザー情報はないので、**ユーザー情報の取得は必然的にCSR（Client Side Rendering）になります。**

例えば認証済みのユーザーでないとホーム画面へリダイレクトするようなページの場合、SSGで既にページ（具体的にはユーザー情報表示の枠組み部分）が作成されており、CSRでユーザー情報について取得後にホーム画面へリダイレクトされます（その過程で、一瞬ページのコンテンツが表示（フラッシュ）されるという注意点があります）。

## サーバーでレンダリングされるページの認証

クライアント側からリクエストがあってサーバーでページを生成するSSR（Server Side Rendering）では、getServerSideProps関数内でユーザー情報をAPIで取得する処理を実装します。

getServerSideProps関数内の処理が終わるまでページはレンダリングされないので、SSGのリダイレクト前のコンテンツのフラッシュを防ぐことができます。しかしその一方、ユーザー情報取得処理を高速に行う必要があります。

Next.js公式ドキュメントでも、**ユーザー情報取得処理を高速化できない場合はSSGを検討するようにとする記載があります。**

# NextAuth.jsという選択

ではSSG＋CSRでどのように認証機能を実装するか？

[NextAuth.js](https://next-auth.js.org/)というNext.js用のオープンソースの認証機能ライブラリがあります。

こちらはデータベースの有無に関わらず、GoogleやTwitterなどのソーシャルログインやメールリンク認証など、**あらゆるパスワードレス認証機能に対応**しています。

パスワードレス認証とはその名のとおり「パスワードがない」認証です。

これまでのID（メールアドレス）とパスワードを使用した認証機能には、

- セキュリティの課題（パスワードリスト攻撃：攻撃者が入手したID・パスワードのリストにより正規ルートから不正アクセスを試みるサーバー攻撃の）

- コスト（パスワード紛失）

の潜在的な課題がありました。

パスワードレス認証は、「パスワードがない」ことで、上記課題を根本から解決することができます。

NextAuth.jsはユーザーの機密情報（パスワード！）を保存する必要がないように構築されており、簡単にNext.jsプロジェクトへパスワードレス認証を導入することができます。

今回のプロジェクトでは、セキュリティ面もふまえてNextAuth.jsを採用することにしました。

# 認証機能実装

それでは早速NextAuth.jsで認証機能を実装していきます。

### 1. API実装

プロジェクトにNextAuth.jsをインストールし、pages/api/authディレクトリ内に**[...nextauth].js**ファイルを作成します。

```javascript:[...nextauth].js
import NextAuth from 'next-auth'
import Providers from 'next-auth/providers'

export default NextAuth({
 // Configure one or more authentication providers
 providers: [
   Providers.GitHub({
     clientId: process.env.GITHUB_ID,
     clientSecret: process.env.GITHUB_SECRET
   }),
   // ...add more providers here
 ],

 // A database is optional, but required to persist accounts in a database
 database: process.env.DATABASE_URL,
})
```
[NextAuth.js公式Docより引用](https://next-auth.js.org/getting-started/example)

上記コードはGithubログイン実装の例です。

**GITHUB_ID**と**GITHUB_SECRET**はGithubのDeveloper settingsから取得して、**.env.local**ファイルに保存します。（GithubでのAuthorization callback URLはアプリURL/api/authとします。）

また、**.env.local**ファイルにはNEXTAUTH_URLの環境変数も追加します。今回の例ではローカルなのでhttp://localhost:3000/api/authを記述しました。

**上記コードのprovidersの部分を変えることで、さまざまなソーシャルログインの実装ができます。（もちろん複数も実装可能です。）**

今回の例ではデータベース連携は実装しませんが、databaseの部分にデータベースの情報を記述することで、簡単に連携ができます。

### 2. フロントエンド実装

フロントエンド部分にはnext-auth/clientからsignIn, signOut, useSessionをインポートしてログインボタン/ログアウトボタンを実装します。

下記の例ではログイン/ログアウトボタンの表示をsessionによって切り替えています。

```javascript:index.jsx
import { signIn, signOut, useSession } from "next-auth/client";
export default function Home() {
 const [session, loading] = useSession();
 return (
   <>
     {!session && (
       <>
         サインインしてください。 <br />
         <button onClick={()=>signIn}>Sign in</button>
       </>
     )}
     {session && (
       <>
         サインイン完了。 email: {session.user.email} <br />
         <button onClick={()=>signOut}>Sign out</button>
       </>
     )}
   </>
 );
}
```
signInは何も指定しなければ、後述の簡易的なログインページにリダイレクトするメソッドです。signOutは名前のとおりログアウトです。

重要なのが**useSession hook**です。

NextAuth.jsはsession をログして見ると、アクセストークンやユーザー情報が入っているのが分かります。

```
{
 user: {
   name: string,
   email: string,
   image: uri
 },
 accessToken: string,
 expires: "YYYY-MM-DDTHH:mm:ss.SSSZ"
}
```
[NextAuth.js公式Docより引用](https://next-auth.js.org/getting-started/client)

**ログインしていない場合sessionはnullになるので、sessionによりボタン表示を切り替えることができます。**

さらに_app.tsxで next-auth/clientからインポートした<Provider /> でラップし、page間でsession情報を共有できるようにします。

```javascript:index.jsx
import { Provider } from "next-auth/client";
export default function App({ Component, pageProps }) {
 return (
   <Provider session={pageProps.session}>
     <Component {...pageProps} />
   </Provider>
 );
}
```

ここまででdevサーバーを起動し、ログインボタンをクリックすると、NextAuth.js が指定したプロバイダでログインページを作ってくれているのが分かります。

![prisma2](//images.ctfassets.net/q5y6t65v3t0p/3uAYs8ifiNrPlvo0sS57j2/6717ffa2c050fce26af05440231f3643/picture_pc_38fae73468ca3f3ef2626efe48998f6e.png)

**とても少ない記述量で認証機能が実装できました！**

上記の例ではデータベース連携は実装していませんが、NextAuth.jsではMySQL、MariaDB、PostgreSQL / CockroachDB等さまざまなデータベースとの連携がサポートされています（公式ドキュメントに[...nextauth].jsでの各データベース連携のサンプルコードがあります）。

また、サインインページも自動的に作成されるページではなく、自分で作成したページを使用することができます。

# 認証されたユーザーの制御

ではログイン後のユーザーをどのように制御するか、具体的な事例でみていきます。

先ほどログイン/ログアウトボタン表示切り替えの例を挙げましたが、仕組みは一緒で、useSession hookを使います。

例えばユーザーのプロフィールページの場合、プロフィールページへのリンクはログイン前には表示させないようにします。

さらに、プロフィールページの方で、ログインしていないユーザーがプロフィールページへアクセスした場合は"/"ページにリダイレクトするようにします。

```javascript:index.jsx
import { useRouter } from "next/router";
import { useSession } from "next-auth/client";
import Link from "next/link";

export default function MyPage() {
 const router = useRouter();
 const [session, loading] = useSession();

 if (loading) {
   return <div>Loading....</div>;
 }
 if (!session) {
   router.push("/");
 }

 return (
   <div>
     MyPage
     <p>{session.user.name}</p>
     <img src={session.user.image} />
     <Link href="/">HOMEにもどる</Link>
   </div>
 );
}
```

ちなみにローディング中はLoading....と表示するようにしています。

簡単な例ですが、こちらも少ない記述量でユーザーの制御をすることができました！

# まとめ

NextAuth.jsを利用することで、とても簡単に認証機能を実装することができました。

上記ははじめの第一歩として簡単な例ですが、次回はデータベース連携についてまとめられたらと思っています。

それでは、また次回です！

nextauth

NextAuth.jsで認証機能実装

Web基礎知識まとめシリーズ、今日はCookieとSessionについて、それぞれの違いをまとめます。

# 前提：HTTPはステートレスなプロトコルである
HTTPは、クライアント側からサーバーへリクエストし、サーバーからレスポンスを返す一往復で通信が切断されます。

そしてそのあと再度クライアント側からリクエストを送信しても、サーバーはそのリクエストが初めてのものなのか、前からの続きなのか記憶していません。

このようなサーバーの状態のことを、**State（状態）less（〜のない）、ステートレス**といいます。

しかし、ログイン状態やショッピングカートの中身など、前の通信時の状態を覚えておいてほしい場合があります。
ページ遷移するたびにログアウト状態になったり、カートが空になっていては大変です。

そこで、状態を保持するためのものがCookieです。

# Cookieとは
**Cookieとは、クライアントに保存される小さなデータ（文字列のみ）です。**
サーバーへアクセスするたびに自動生成され、サーバーとのやりとりで合言葉のように使います。

1. サーバーからのレスポンスメッセージに「Cookieを保存してください」という指示があれば、クライアントは指示に従い、Cookieを保存します。
2. クライアントにCookieが保存されていれば、クライアントは、常にリクエストメッセージに「このようなCookieがあります」とサーバーに教える仕組みになっています。

サーバーは、Cookieによって、アクセスしてきた相手が誰なのか調べることができるのです。

## 具体的な流れ
#### 1. サーバーがレスポンスにSet-Cookieヘッダを付与

```
Set-Cookie: name=value;
```

##### Set-Cookieヘッダフィールド

- **NAME=VALUE** ：　　Cookieにつける名前とその値（必須）
- **Expires=DATE**　　：　　Cookieの有効期限（デフォルトはブラウザを閉じるまで）

※過去の日時を指定するとCookieが削除される
- **Max-Age=DATE**　　：　　クッキーの残存期間を秒数で指定

※ExpireとMax-Age両方指定した場合はMax-Ageが優先される
- **Path=PATH**　　：　　Cookieの適用対象となるサーバ上のパス（デフォルトはドキュメントと同じパス）
- **Domain=DOMAIN**　　：　　Cookieの適用対象となるドメイン名（デフォルトはCookieを生成したサーバのドメイン名）

※複数のドメインを対象にする必要がない場合は指定しないほうが安全
- **Secure**　　：　　HTTPSで通信している場合にのみCookieを送信するオプション
- **HttpOnly**　　：　　CookieをJavaScriptからアクセスできないように制限するオプション

#### 2.レスポンスを受け取ったクライアントはCookieをブラウザに保存

#### 3.それ以降のリクエストには受け取ったCookieをヘッダに入れてリクエスト

```javascript
Cookie: name=value;
```

## Cookieのセキュリティ上の問題点
CookieはHTTPOnly属性をつけないと、JavaScriptからの読み書きができてしまいます。

セキュリティ上は注意が必要です。

# Sessionとは
**Sessionとは、一連の処理の始まりから終わりまでを表す概念のことです。**

ECサイトのような同一利用者からのアクセスを関連性のある一連のアクセスとして扱いたい場合、Cookieを使ってSession管理が行われます。

1. クライアント側でユーザーがログイン、ユーザーIDとパスワードをサーバーに送信する
2. サーバー側でセッションIDを生成し、Coockieに載せて返す
3. クライアント側でセッションIDを管理し、リクエストのたびにCookieヘッダにセッションIDを含めて送信

クライアント側はCookieにセッションIDを載せてリクエストすることでセッションの維持ができるようになります。

## Sessionの保存期間
ブラウザがサーバーに接続されている間（ブラウザを開いている間）サーバーに保存されます。


Cookieとセッションについての簡単なまとめ

cookie

CookieとSession

こんにちは！

今回は、現在開発中のプロジェクトで使用しているNext.jsについて、知らないことばかりで勉強になったので、簡単にまとめてみようと思います。

# Next.jsとは

[Next.js](https://nextjs.org/)とは、Reactの機能を拡張するためのJavaScriptフレームワークです。

Next.jsは、2016年にVercel社によりバージョン1.0がリリースされ、現在も開発が継続されています。

# Next.jsの特徴

## SSR（Server Side Rendering）とSSG（Static Site Generator）

ReactはSPA(Single Page Application)として単一の巨大なJavaScriptを生成します。

SPAはブラウザによるページ遷移を行わずにコンテンツの切り替えなどを行うことで、ユーザー体験（UX）を大きく向上させることができますが、今までサーバー側で行っていたHTML生成をブラウザ側で行うことになるため、初期ローディングの時間がかかったり、通常のWebページと比べSEOの面で不利になるというデメリットがあります。

それに対して、**Next.jsはアプリケーションを事前にページ単位でレンダリングします。**

クライアント側からのリクエスト時にレンダリングするのがSSR(Server Side Rendering)と呼ばれる機能です。また2020年3月リリースのv9.3より、ビルド時にレンダリングするSSG(Static Site Generation)と呼ばれる機能も追加されました。

これらの機能により、各ページ読み込み時のダウンロードファイルサイズを削減できます。またURLごとに個別のHTMLが生成されるので、SEOに有利です。

> ちなみに、SSRとSSGの切り替えはビルド時にNext.jsが自動的に判断します。getServerSidePropsなどSSR用のメソッドが使われていればビルド時には静的ファイルを作成しません。反対に、それらが使われていなければビルド時に自動で静的ファイルの生成までやってくれます。（素晴らしい・・・）

## Next.jsはSSRのためのフレームワークではない

Next.jsはSSRのためのフレームワークという印象がありましたが、現在（v10.0.9）、下記のとおりStatic Site Generation(SSG)が推奨されています。

> We recommend using Static Generation over Server-side Rendering for performance reasons. Statically generated pages can be cached by CDN with no extra configuration to boost performance.
>
>[Basic Features: Pages | Next.js](https://nextjs.org/docs/basic-features/pages)

**SSGは、ビルド時にすべてのページを生成するため、リクエストごとにページ生成するSSRよりも高速です。**

Next.jsはこのパフォーマンスをウリにしていて、「どや、ウチの速いやろ・・・ええからSSG使ってみ」と言ってるわけなんですね。

## ISG（Incremental Static Generation）

SSGでは、**getStaticProps関数**により、ビルド時にデータを取得してページにデータを渡すことができます。

```javascript
export async function getStaticProps(context) {
 return {
   props: { 渡したいデータ }, 
 }
}
```

また、**getStaticPaths関数**により、一覧ページ→詳細ページのような動的な（臨機応変な、柔軟な）ページ遷移にも対応しています。

```javascript
export async function getStaticProps(context) {
 const postId = context.params.id // context.paramsによりpathsで指定したparamsを参照
 const post = postIDによるpostデータ取得処理

 return {
   props: { postId, post },
 }
}

export async function getStaticPaths() {
 return {
   paths: [ // 生成されるページのURLのパス一覧
       { params: { id: 'my-first-post' } },
       { params: { id: 'my-second-post' } },
       { params: { id: 'my-third-post' } }, 
   ],
   fallback: false
 }
}
```

上記コードでは、**https://example.com/posts/選んだid**にアクセスすると、idに対応したデータ内容が表示されたページを取得することができます。

なお、getStaticPaths関数には必ず**fallbackキー**を記述します。

pathsにないパスに対してリクエストがあったときに、fallbackキーの値によって挙動の違いがあります。

>false：404ページを返す
>
>true：まずはデータ取得が必要な部分以外を返してからデータ取得が行われる
>
>blocking：”データ取得が必要な部分以外を返す”という動作をブロックして（＝行わず）、データ>取得が終わってからページ全体を返す（v10より追加）

**getStaticPaths関数の例のように、段階的に（クライアント側からのリクエストにより）ページが静的に生成される機能の総称をISG（Incremental Static Generation）といいます。**

## SSGの問題点

SSGは前述のとおりビルド時にデータを取得してページに表示します。

ここで問題が発生します。

ビルド以降、データが更新されたらページに反映されないのです。（例：一覧データが増えても反映されない）

外部データの取得をクライアント側で行うと、結局CSRによって成り立っているのと同じ。

なるべくSSGを使いたいが、規模が大きくなるほど使い勝手が悪くなる・・

そこでv9.4より登場したのがISRです！

## ISR（Incremental Static Regeneration）

直訳すると"段階的静的**再**生成"とあるように、

ISRは**クライアント側のリクエストに対しビルド時に生成された静的ページを返し、かつバックグラウンドで一定期間ごとに静的ページの再生成をサーバー側で行います。**

これにより、SSGの問題点に対応できます！

### getStaticProps関数にrevalidateを追加

具体的にコードで見ます。

```javascript
export async function getStaticProps(context) {
 const postId = context.params.id
 const post = postIDによるpostデータ取得処理
 return {
   props: { postId, post },
   revalidate: 30, // ここを追加
 }
}
```

getStaticProps 関数から return するオブジェクトの中で、**revalidate**というキーに対して秒数を指定します。ここでは30秒を指定しています。

つまり**30秒経過後クライアント側からリクエストがあったら、クライアントには既に生成されたページを見せつつ、バックグラウンドでデータの再取得及び再レンダリングを行いページを再生成し、次のリクエストに対しては再生成されたページを返します。**

これによって、データの変化も反映することができます。

revalidateで秒数を指定するだけ。凄い！

しかし、Next.jsについて予備知識がなさすぎて、凄い！までたどり着くのに時間がかかりました。

# まとめ

実装したい機能をふまえ、どの技術を使うべきか？

そもそもフレームワークやライブラリについて知らないものも多く、その中から何を選択するのが最適か、試行錯誤の日々です。

Next.jsについては、またまとめていこうと思います！

Next.jsの特徴とIncremental Static Regenerationについて

amazing

Next.jsのIncremental Static Regenerationが凄い

なんとなくわかったつもりになっていたCORSについて、ちゃんと理解するためにまとめてみました。

# CORSとは
**Cross-Origin Resource Sharing**、日本語訳すると**オリジン間リソース共有**のこと。

## Originとは
オリジンとは、プロトコルとドメイン、ポート番号のこと。

#### プロトコル、ドメイン、ポート番号
- **プロトコル**：ルール、決まり。この決まりでリクエストします、という宣言。
- **ドメイン**：インターネット上の住所。
- **ポート番号**：玄関の番号。

## 前提としてのSame Origin Policy
クライアント側のWebアプリケーションに適用されるセキュリティルールの１つ。
日本語訳すると**同一オリジン（生成元）ポリシー**。

>同一オリジンポリシーは重要なセキュリティの仕組みであり、あるオリジンから読み込まれた文書やスクリプトが、どのように他のオリジンからのリソースと対話することができるかを制限するものです。悪意ある行動を起こしかねないリソースを分離し、攻撃の可能性を縮小するのに役立ちます。
>[MDNより](https://developer.mozilla.org/ja/docs/Glossary/Same-origin_policy)

現代の主要なブラウザはすべて、Same Origin Policyに基づく制限を実装しています。

簡単に言うと、JavaScriptで自由にやりとりできるところは、そのJavaScriptをとってきたところと同一の場所だけに制限されるのです。

同一オリジンかどうかは、前述のとおりホスト、ポート番号、プロトコルによって判断されます。
ホスト、ポート番号、プロトコルのいずれか1つでも違う場合はSame Origin Policyの対象となってリクエストに失敗します。

### つまり、CORSとは
CORSは、原則Same Origin Policyによって同一オリジン間でないとできないやりとりを、異なるオリジン間でも安全に許可する方法です。

# 具体的な実装方法
CORSは、HTTPリクエストを行う際のヘッダーに情報を記述します。

まず、HTTPリクエストを「単純なHTTPリクエスト（シンプルリクエスト）」と「単純でないHTTPリクエスト（プリフライトリクエスト）」に分類します。

### 単純なHTTPリクエスト（シンプルリクエスト）
- HTTP のメソッドとして**GET、POST、HEAD**を使う
- Accept、Accept-Language、Content-Typeなどの基本的な HTTP ヘッダーがセットされただけのリクエスト（そのうちContent-Typeは**text/plain、application/x-www-form-urlencoded、multipart/form-data**の値がセットされたもの）

以上にあてはまるものは、「単純なHTTPリクエスト」として**そのままリクエストを送信し、サーバーからの応答をチェック**します。

#### シンプルリクエストのながれ
1. ブラウザがリクエストに**Originヘッダー**を追加（リクエストの送信元の情報がセットされる

```javascript
Origin: https://test.co.jp
```

2. サーバー側でOriginヘッダーをチェックしてリクエストを許可するか判断
3. 許可する場合、**Access-Control-Allow-Originヘッダー**をセットして応答を返す

```javascript
Access-Control-Allow-Origin: http://test.co.jp //特定のサイトを許可
Access-Control-Allow-Origin: *   // 全てのサイトを許可
Access-Control-Allow-Headers "X-Requested-With, Origin, X-Csrftoken, Content-Type, Accept"  //フレームワークにより異なる
```

4. ブラウザ側のJavaScriptは、サーバーから許可があることを確認してからレスポンスデータを渡す（許可がなければエラーとなる）

### 単純でないHTTPリクエスト（プリフライトリクエスト）
シンプルリクエスト以外のHTTPリクエストは単純でないHTTPリクエスト（プリフライトリクエスト）に分類されます。

プリフライトリクエストの場合、ブラウザのJavaScriptから**サーバーに事前問い合わせ（プリフライト）を行い、アクセスが許可されるか確認します。**

#### プリフライトリクエストのながれ
1. リクエストの始めに**OPTIONSメソッド**で対象の異なるオリジンにリクエストを送り、実際のリクエストを送っても問題ないか確認
2. Originヘッダーの他、**Access-Control-Request-MethodヘッダーやAccess-Control-Request-Headersヘッダー**を使う
3. サーバーはアクセスを許可する場合、Access-Control-Allow-Originヘッダーの他、**Access-Control-Request-MethodヘッダーやAccess-Control-Request-Headersヘッダー**を返す
プリフライトの有効期間となる**Access-Control-Max-Age**も設定

```javascript
Access-Control-Allow-Methods: PUT, DELETE, PATCH
```

4. サーバーのアクセス許可が確認できてから、実際のHTTPリクエストが送信される

# まとめ
CORSの基本的な部分について理解できました。
今後は具体的な実装方法についても勉強していきます！


CORSの基本についてまとめてみます

server

CORSの基本

Web全般の基礎知識まとめシリーズ、今回はTCP/IPについて調べてまとめてみます。

# TCP/IPとは
TCP/IPはインターネットなどで世界標準的に使われる通信プロトコルで、TCP（Transmission Control Protocol）とIP（Internet Protocol）を組み合わせたものです。

## プロトコルとは
簡単にいうと、**通信を行う際のルール、決まりごと**です。

私たちがWebサービスを利用する際、ネットワーク上で機器同士がデータ交換を行っています。

機器同士のデータ交換の際、ルールがないとスムーズにデータ交換ができません。

データはいろいろな要素が送られてくるので、データが送られてくる順番を決めておかないと何が送られてきたのかわからなくなります。

>例えるなら、手紙のやりとりですね。
手紙を郵送する際、「郵便番号」「住所」「宛名」を書いてポストに入れることで、相手に手紙を届けることができます。

# 情報通信ネットワークのしくみ
ネットワーク上のデータの送受信は、データをパケットという小さい単位に分割するパケット交換方式がとられています。

パケットには送りたいデータの他に、送信元や宛先の所在を表す情報（アドレス）などの制御情報が付加されます。

#### パケット交換方式でのデータ送受信のながれ

1. 送信側は、送りたいデータを定められた長さごとに分割し、制御情報を付加して順番に送信する
2. 中継機器は受け取ったパケットをいったん自分の記憶装置に格納し、次の中継機器へ送る
3. 2を繰り返して受信側にパケットたちが届く
4. 受信側はパケットからデータを取り出して順番につなぎ、元のデータに復元する

各パケットは同じ経路を通る必要がなく、自由に経路を選択できるため効率よくデータ送信ができます。

中継機器でいったんデータを蓄積するので、異なる通信速度や通信方式も接続しやすい上に、制御情報に誤り検出・訂正符号を付加して、伝送途上で生じたデータの破損を検知して修復したり、再送要求を送ることもできます。

データの送受信前にデータの通信経路を確保し、データ送受信が完了するまで経路を専有する**回線交換方式**という方法もありますが、多くのユーザーがデータをやりとりするようになった現在、効率のよい方法ではありません。

# 通信プロトコルの種類
通信プロトコルには、いくつか種類があります。
ネットワーク上で各通信プロトコルが各役割を果たすことでクライアントとサーバーのデータ交換を可能にしています。

最初に述べたように、TCP/IPも通信プロトコルです。

## 階層型プロトコル
### OSI参照モデルとTCP/IP
「OSI参照モデル」とは、国際標準化機構（ISO)によって取り決められた7階層からなる、通信機能の分割モデルです。
"モデル"とあるように、OSI参照モデルは概念であり、すべてのネットワーク機器、コンピュータに実際に採用される目的で1977年から標準化が進められていました。

対してTCP/IPはインターネットの原型となったプロジェクトから生じたプロトコル群です。

TCP/IPの世界的な普及により、OSI参照モデルは概念として残ることになりました。

OSI参照モデルとTCP/IPはともに階層構造ですが、通信に対する概念が異なるため区切られている層が異なります。

![TCPIP](//images.ctfassets.net/q5y6t65v3t0p/6LBwk5egNDjPU2hTQJGpzv/b0b3fcdd54866024f6d9e7e316e86576/tcpip.png)

層の番号が大きいほどソフトウェア的で、層の番号が小さくなるほど物理的になります。

TCP/IPは、4つの層のプロトコルが正常に機能してはじめて通信ができます。

では、各層の役割と例を簡単にまとめます。

## 1層：ネットワークインターフェイス層
**同一のネットワーク内でデータを転送する**

有線の「Ethernet（イーサーネット）」や無線LAN（Wi-Fi）、PPPなど

## 2層：インターネット層
**複数のネットワーク間のデータ転送を行う役割**

IPアドレスを用いた通信方法

「IP」「ICMP」「ARP」など

## 3層：トランスポート層
**データを適切なアプリケーションに振り分ける役割**

主なプロトコルはTCPとUDPに分けられます。

#### TCP

送信中にデータが破損してしまったり損失してしまっても、これらを検出してデータの再送を行い確実に通信をしてくれる

例：WebサイトのWebページを閲覧したりメールの送受信を行うなどインターネットで実行する通信方法の殆ど

#### UDP

正確性はないが、素早くデータを送信する際に適した方法

例：Web会議や動画サイトの映像と音声の通信方法で、リアルタイムに通信をする方法

## 4層：アプリケーション層
**アプリケーションで扱うデータのフォーマットや手順を決める役割**

「HTTP」「SMTP」「POP3」「IMAP4」「DHCP」「DNS」など

HTTPはWebブラウザで利用し、SMTP、POP3は電子メールソフトで利用します。DHCP、DNSはアプリケーション通信を行うための準備のプロトコルとして補うことを担います。

# 参考
[TCP/IPとは？通信プロトコルの階層モデルを図解で解説](https://www.itmanage.co.jp/column/tcp-ip-protocol/)

[TCP/IPをわかりやすく - 通信プロトコルの基礎知識を図解で学ぼう](https://eh-career.com/engineerhub/entry/2020/02/13/103000)

[OSI参照モデルとTCP/IPの階層の違いとは？](https://www.sbbit.jp/article/cont1/12099)

[OSI参照モデルとは？TCP/IPとの違いを図解で解説](https://www.itmanage.co.jp/column/osi-reference-model/)


TCP/IPとは？通信プロトコルとは？

protocol

TCP/IPとは、通信プロトコルのまとめ

Webサーバーとのやりとりについて、改めてまとめてみます。

# Webサーバーのレスポンスは何をしているか
**クライアントからの指示を受け取り、その内容に応じた情報を送り返す**処理をしています。

具体的には、

クライアントからのリクエストを解釈し、サーバー上に用意された該当ファイルを返す処理です。

# 主なWebサーバー
Apache

Nginx

# HTTPとは
HyperText Transfer Protocol（ハイパーテキスト・トランスファー・プロトコル）の略で、**通信プロトコル（通信するときのルール）の１つです。**

ホームページのファイルを受け渡しするときに使います。

HTMLやXMLなどのハイパーテキストだけでなく、静止画、音声、動画、JavaScriptプログラム、PDF、各種ドキュメントファイルなど転送することができます。

やり取りされる内容を暗号化する通信プロトコルがHTTPSです。

# HTTPリクエストの種類
## GET

- URIで指定した情報を要求
- URIがファイル名のときはそのファイルの中身を、プログラム名のときはそのプログラムの出力を返す
- URIにデータをつけて送る（クエリ文字列はブラウザのURL欄に表示される）
- stringのみ
- 何か情報を検索したり取得する等、基本的に読み取り専用な機能に対して使うべき

## POST

- HTTPリクエストのメッセージボディにパラメータ（情報）を付けて送る
- HTTPヘッダのみを返す
- 新しくデータを作成するときによく使用する
- ボディは解析すれば確認できるのでセキュリティ的に安全というわけではない

## PUT

- すでに存在しているデータを上書きして更新

## PATCH

- すでに存在しているデータを上書きして一部更新

## DELETE

- すでに存在しているデータを削除

# HTTPレスポンスの種類
次にレスポンスの主なものをまとめます。

## 200
#### 200
OKリクエストが成功しレスポンスが返されます。正常処理を表します。

## 300
#### 301
Moved Parmanently指定したリソースは移動したので、新しい場所から取得して下さい。サイトの引越しをしたときは、この値を設定します。

#### 302
Moved Temporarily指定したリソースは一時的に移動したので、新しい場所から取得して下さい。一時的にサイトの場所を変える時にこの値を設定します。

#### 304
Not Modified指定したファイルは変更されていないのでブラウザのキャッシュのデータを表示してください。

## 400
#### 401
Unauthorixed認証に失敗しました。

#### 403
Forbiddenアクセス権がありません。

#### 404
Not Foundリクエストしたアドレスのページがありません。

## 500
#### 500
Internal Server Errorスクリプトなどで内部のエラーが発生しています。

#### 502
Bad Gatewayゲートウェイが無効なレスポンスを受け取りました。

#### 503
Service Unavailableサービスが提供できません。Webサーバーに負荷がかかりすぎたときなどに表示されます。

# まとめ
簡単に、備忘録としてまとめてみました。


develop

Webサーバーとリクエスト

1月にエンジニア転職して、早くも4ヶ月が経過しました。
今日は、どんなふうに仕事をしているのか、それについて思うことを書いていきたいと思います。

# 入社２日目からフルリモート勤務
昨年4月から、エンジニアに限らず基本的にフルリモート勤務となっている現在の会社。

1月に入社し、初日はPC支給や入社手続きのため出勤しましたが、**2日目より早速フルリモートでの勤務が始まりました。**

しかも、エンジニアチームのメンバーとはほぼ顔を合わせていない状態でのリモート勤務開始。

不安・・でしたが、チームではフルリモートでもスムーズに仕事ができるよう、いろんな工夫をしています。

## コミュニケーションツールの組み合わせ

チームの基本的なコミュニケーションは[Workle（ワークル）](https://workle.info/)で行っています。

このWorkle、「空間型グループ会話ツール」と謳ってあるとおり、バーチャルルームに入室すると入室中のユーザーのアイコンが表示されていて、リアルのように近づくと話ができるというサービス。
ユーザーのアイコンも「会話する・着席中・離席中」のモードが選べる仕様になっており、顔が見えなくても話しかけやすいです。

とはいえ、コードを書いていてわからない点を聞くのに口頭で説明するのも限界があるので、Slackでスクリーンショットを送ったり通話で画面共有して解決しています。

また、定例ミーティングを週に1回zoomで行い、各々自分の担当プロジェクトの進捗を報告しています。（これが、入社当時結構助かりました。自分が携わっていないプロジェクトのことが把握できます。）

このようにさまざまなツールを組み合わせることで、チームのコミュニケーションをとっています。

## 幅広い業務内容
この1ヶ月で、

- Adobe XDを用いたデザイン作成

- 新規プロジェクト打ち合わせ

- Reactでの開発

- 既存システムのカスタマイズ

- サーバー開発環境構築（少し触った程度ですが）

と、**入社前に自分が考えていたより、ずっと幅広い業務を行いました。**

特に新規プロジェクトについては、サービスの目的から技術選定、デザインまで、フロントエンドやバックエンドの垣根を超えてチームメンバーで話し合いながら進めています。

難しいですが、これが楽しい！

ただ設計どおりにコードを書くのではなく、自分たちであれこれ考えて意見を出し合いながら、少しずつサービスを作っていくことにやりがいを感じています。

# エンジニアに転職して感じたこと
## "チーム"での開発ということ
転職する前は、1人で仕事をするイメージがありましたが、まったくそんなことはありませんでした。

開発方法やデザインパターンについて意見交換したり、とにかくコミュニケーションをとることが多い！

**コミュニケーション大事。**

社会人なら当然ことですが、チーム開発やフルリモートでもあり、より実感しています。
何なら今までの対面で仕事していた頃より大切さを感じてます。

あまりお互いのことがわからない状態でコミュニケーションをとるので、ちょっとしたことで誤解が生じやすい。

通話の口調を明るくしたり、雑談をしたり、一緒に働きやすいと思ってもらえるよう心がけています。
特にSlackなどテキストだけでコミュニケーションをとることは今までなかったので、すぐリアクションするようにしたり、一度文章を見直してメッセージを送ったりしています。

## 基礎知識がない
入社前は独学で勉強していましたが、実務に入ると知識不足、技術力不足を実感しています。

バックグラウンドがないため、特に情報系の大学を卒業している方だったら当然知っているような基礎的な部分の知識（Webのしくみなどの前提知識）がないことを日々痛感しています。

これまではフレームワークやライブラリを使って、とにかく動くコードを書くことで必死でしたが、これからは基礎的な土台の部分も含めてインプットしていく必要があります。（本当はそこからですよね、反省。。）

勉強することは多い・・・ですが、今の自分は伸び代しかない！とポジティブに捉えて日々勉強しています。

# まとめ
こんなかんじで、なんとか日々過ごしてます。

この歳になって未経験の世界に飛び込み、本当に1から仕事をしていると、なんだか新卒の頃を思い出します。

今後も謙虚に、エンジニア修行続けていきます。


home

転職して4ヶ月経って思うこと

# レンダリングの前に

ユーザーがWebブラウザにURL入力すると、ブラウザはURLをもとに指定のサーバーへTCP/IPプロトコルに基づいてリクエストを送り、サーバーからレスポンスが返ってくる

レスポンスとして受け取ったHTML,CSS,JavaScriptをどう表示するのか？=レンダリング

# レンダリングの流れ

この工程は、critical rendering pathと呼ばれている

## １．HTML parse

DOM（Document Object Model）ツリー構築

1-1.ブラウザはディスクやネットワークからHTMLのバイトを読み取り、utf8などの文字コードに応じて<html>や<head>のような文字列に変換

1-2.取得した文字列をトークンに変換

1-3.トークンを<html>や<head>といったオブジェクトに変換（字句解析）

1-4.オリジナルのマークアップの定義に基づいた親子関係をもつ木（ツリー）構造に整形

## ２．CSS parse

 CSSOM（CSS Object Model）ツリー構築

ブラウザでDOMを構築している際にドキュメントのheadタグで外部のcssスタイルシートを参照しているlinkタグに遭遇すると、ブラウザはページのレンダリングにこのリソースが必要であると解釈してこのリソースに対するリクエストを即座にディスパッチし、CSSを受け取る

## ３．JavaScript 実行

⚠HTML parseの途中でJSに出会うとHTML Parsing を見合わせる

## ４．レンダーツリー生成

DOMツリーとCSSOMツリーを合成してレンダーツリーを生成

ページの描画に使われる全てのDOMと個々のオブジェクトに使われるCSSをそれぞれ組み合わせる

## ５．レイアウト

デバイスのviewport内でそれら要素（Node）の厳密な位置やサイズを算出するレイアウトの工程（リフロー）

## ６．ペイント

レイアウトプロセスで得ることができた個々の要素のサイズと位置情報を最終的な正確なピクセル値へと変えるペイント(又はラスタライゼイション)の行程


ブラウザレンダリングのしくみ

# はじめに
こんにちは。 
わたしは現在フロントエンドエンジニアとして勤務していますが、現在の会社には**実務未経験で働きながら独学5ヶ月で転職しました。**
ブログ初回である今回は、学習開始から転職活動〜内定までを振り返ってみたいと思います。

# 未経験から内定をもらうには？
未経験からエンジニア転職は難しいと言われていますが、わたしのような**文系未経験30代でも自社開発企業に転職することができました！**

働きながら学習＆転職活動を進めましたが、

**・フロントエンドエンジニア志望でもしっかりポートフォリオを作成すること(=自走力のアピール)**

**・自己分析を行い、過去の職歴に基づく強みをアピールすること(=自分の強み、会社への適正のアピール)**

が重要だと思いました。　

# わたしの経歴について
地方国立大学文系学部卒業後、法律事務所勤務を経て地方公務員として働いていました。
学生の頃、趣味でホームページを作成した経験はあるものの、HTML/CSS以外のプログラミング言語についてはまったく知らない状態でした。

## 準備（2020年4月頃）
まずはじめに以下の環境を整えました。

- PCを購入（MacBook Air)
- VScodeインストール
- iTerm2インストール
- 学習用Twitterアカウント開設

また、短期目標として下記を設定しました。
- 5月でインプット
- 6〜7月でポートフォリオ作成
- 8月〜転職活動開始、年内に転職先決定

## 1ヶ月目（2020年5月）：Webデザイン＆コーディング
まず最初にWebデザインとコーディングの学習から始めました。
**書籍**や**Udemy**でインプットし、まずはサイト模写などのアウトプットを行いました。

また、学習用に開設したTwitterアカウントで日々の積み上げやトレースしたバナーをつぶやいたり、自分と同じように勉強している方を見つけたりしてモチベーションを上げていました。

## 2ヶ月目（2020年6月）：Webアプリ開発
フロントエンドエンジニアは幅広いので、その中で自分がどの道へ進みたいのか考えました。
ざっくり分けるとLP制作などのコーディングをメインにした**Web制作**か、**Webアプリ開発**か。
ここでWeb制作だとWordPressなどの学習を進めるようになります。

わたしはWebアプリやシステム開発したい！と思ったので、**Webアプリ開発の学習へ！**

**JavaScriptで簡単なToDoリスト**を作ったり、チュートリアルを参考にJavaScriptフレームワークの**Vue.jsでチャットアプリ**を作ったりしました。

## 3ヶ月目（2020年７月）：ポートフォリオ作成
未経験から転職活動を行うにあたり、**学習の成果や技術レベルを客観的に証明できるポートフォリオは必須**です。

わたしは

**①ログイン認証のない、誰でも気軽に利用できるWebアプリ** : [YATTA!](https://yatta.tokyo/)

**②ログイン認証があり、データベースへのCRUD処理ができるWebアプリ** : [Kusuri](https://kusuri-chat.web.app/)

**③ポートフォリオサイト** : [Meg's Portfolio](https://meg-portfolio.site/)

の３つを作成しました。

### ポートフォリオのアイデア
チュートリアルをそのままポートフォリオにするのではなく、「なにか困っていることを解決したい」というような**自分でアイデアを考え工夫して開発すること**が大切だと思います。
**面接では必ずポートフォリオについて質問があるためです。**

わたしは、”誰もが簡単に発言できる時代だからこそ、ひと手間かけて相手に気持ちを伝えることの大切さ”や”嬉しいできごとを共有して皆がHappyになってほしい”という想いから
①のアプリについては嬉しい出来事をカードにしてTwitterでシェアできるアプリ
②のアプリは嬉しい出来事をユーザーで投稿して共有できるアプリ
を考え、**ユーザーフレンドリーを意識してあえてログイン認証のないものにしたりデザインを工夫しながら開発しました。**

### 使用言語
JavaScriptのフレームワークやライブラリである**Vue.js**や**React**などを使用するのがよいと思います。
わたしは
・日本語の公式ドキュメントが充実している
・学習コストが低い
などの理由からVue.jsを選びました。
バックエンドについてはBaaS（Backend as a Service)である**Firebase**を利用しました。

### コードはすべてGitHubへ
ポートフォリオで作成した**WebアプリのコードはすべてGitHubにpushしました。**
選考の段階でGitHubのURLを送ってほしいと依頼されることもあったので、すべてpushしておいたほうがよいと思います。

## 4ヶ月目（2020年8月）：転職活動スタート
ポートフォリオが完成したため、さっそく転職活動開始。
**実務経験必須の求人にも積極的に応募しました！**

## 5ヶ月目（2020年9月）：内定
転職活動開始から１ヶ月、面談や面接は５社ほど受け、**第一希望の企業より内定をいただきました。**

## 学習に使用した教材やサービスについて
基本的に書籍とUdemyを利用しインプットして、チュートリアル等でコードを書いていくようにしました。
また、仕事の休み時間などのスキマ時間はQiitaの記事を読んだり、そのときわからないことを調べてまとめるようにしました。

### Udemy
幅広い講座の中から、目的や好みに合った講座を購入できます。
**セール時の購入がオススメです！**

下記、わたしが購入した講座の一部です。

- [HTML/CSS/JavaScript]フロントエンドエンジニアになりたい人のWebプラグラミング講座/たにぐちまこと
- JavaScriptをとことんやってみよう/世界のアオキ
- 誰でも簡単に学べるAdobeXD入門講座/濱野将
- 最短・最速で学ぶFirebase Hosting+Vue Todoアプリ実装/Daiz Academy

### 書籍
__◯1冊ですべて身につくHTML&CSSとWebデザイン入門講座（Mana著）__
第一歩はここから。
__◯JavaScript本格入門__
THE入門書。基礎が大事なので、理解できないところは時間をかけて読み込みました。
ポートフォリオ作成と並行してもOKだと思います。
__◯Vue.js入門__
Udemy講座終了後、ポートフォリオ作成中こちらで復習しました。
__◯Webを支える技術__
Webサービス設計の基礎について学ぶことができます。
__◯リーダブルコード__
読みやすいコードはどうあるべきか？さまざまなパターンが紹介されています。
### 公式ドキュメント
コードを書いていてわからなければまず公式ドキュメントを確認！
### MENTA!
自分に合ったメンターさんと契約できるサービスです。
**コードレビュー**や**転職サポート（職務経歴書の添削など）**をしてもらったり、メンターさんによっては**チーム開発にも参加できる**ので、独学の方は利用をオススメします！
### Youtube
[しまぶーのIT大学さん](https://www.youtube.com/channel/UCti6dG0zSAetLGGYcgNML4Q)のYouTube講座は全体像がわかりやすく、オススメです！

## 転職活動について
### 利用した転職エージェント
__Wantedly__
「まずは話を聞きたい」から企業に連絡をとることができるので、カジュアル面談から入るところが多く気軽に話を聞きやすい。
__Green__
初回応募時に選考理由等フォーム入力するため敷居が高い印象だが、そのぶん初回応募で通ると面接に進みやすい。

### 履歴書、職務経歴書
まず面接の前に提出を求められることが多いため、履歴書と職務経歴書も用意しておきます。
できれば**第三者に見てもらって意見をもらい、校正したほうがよい**と思います。

### 面接対策
面接では**自己紹介**や**エンジニア転職を決めた理由**は必ず聞かれるので、あらかじめ準備しておきました。

また、前述のとおり面接では、**ポートフォリオについて質問があります。**
ただ学習の成果をアピールするだけでなく、
- なぜこのアプリを作ったのか
- 何を解決したいのか
- 工夫した点はどこか
など説明できるように整理しました。

# まとめ
いつ転職を目指すか、どのような学習方法が合っているかは個人によって異なりますので、結局は**自分に合ったやり方が一番**です。
ただ、**やると決めたら徹底的にやること**、それだけです！

今後は技術的な記事や、エンジニア転職後の生活について書いていこうと思います。


SPAとSSR、SSGについて
NEW

Next.js環境変数の取り扱いについて

NextAuth.jsで認証機能実装その２【データベース連携】

NextAuth.jsで認証機能実装

CookieとSession

Next.jsのIncremental Static Regenerationが凄い

CORSの基本

TCP/IPとは、通信プロトコルのまとめ

Webサーバーとリクエスト

転職して4ヶ月経って思うこと

ブラウザレンダリングのしくみ

未経験から独学５ヶ月でエンジニア転職するまでのまとめ

SPAとSSR、SSGについてNEW

Next.js環境変数の取り扱いについて

NextAuth.jsで認証機能実装その２【データベース連携】

NextAuth.jsで認証機能実装

CookieとSession

Next.jsのIncremental Static Regenerationが凄い

CORSの基本

TCP/IPとは、通信プロトコルのまとめ

Webサーバーとリクエスト

転職して4ヶ月経って思うこと

ブラウザレンダリングのしくみ

未経験から独学５ヶ月でエンジニア転職するまでのまとめ

SPAとSSR、SSGについて
NEW