
## Contents

# 개요

최근 진행하는 프로젝트는 NextJS13 app directory를 사용하여 진행하고 있다.

부딪혀가며 배우는 중인데, 까면 깔 수록 자체 제공 기능이 다양하고 서버 컴포넌트가 디폴트이다 보니 기존 라이브러리나 접근법에서 더 신경 써 주어야 하는 것들이 많다고 느낀다.

그 중에서 최근 잘 못하기도 했고 정리도 안 된 데이터 패칭에 대해서 알아보고자 한다.

# 공식 문서

공식 문서에서 제안한 네 가지 데이터 패칭 사례를 살펴보자.

1. 서버에서 fetch
2. 서버에서 타사 라이브러리 사용
3. 클라이언트에서 route handler 사용
4. 클라이언트에서 타사 라이브러리 사용

## 1. 서버에서 fetch 사용

### Caching

NextJS는 기본으로 제공하는 fetch API를 확장하여 사용한다. 즉, 기본 fetch API를 사용하면서 caching이나 revalidating을 커스텀 할 수 있다.

여기서 중요한 점은 React가 fetch에 대해 동일한 URL과 옵션을 가진 요청을 자동으로 memo한다는 점이다.

![230924-213514](/posts/NextJS13에서_axios와_tanstack_query는_유효할까/230924-213514.png)

> If you need to use the same data (e.g. current user) in multiple components in a tree, you do not have to fetch data globally, nor forward props between components.

때문에 NextJS 공식 문서에서는 위와 같이 렌더링 트리의 여러 구성 요소에서 동일한 데이터(예를 들면 현재 사용자 같은)를 요청하는 경우 전역적으로 데이터를 가져오거나, props로 전달하는 등의 노력이 불필요하다고 지적한다.

![230924-213529](/posts/NextJS13에서_axios와_tanstack_query는_유효할까/230924-213529.png)

- 첫 요청에 대해 MISS 처리되어 외부 데이터를 가져오는 과정을 거치고, 메모리에 SET 된다.
- 동일한 렌더링 경로에서 후속으로 처리되는 함수 호출은 요청을 실행하지 않고 메모리에서 반환한다.
- 렌더링 된 후에는 메모리가 reset되어 모든 request memoization이 지워진다.

- 해당 기능은 NextJS 기능이 아닌 React의 기능이다.
- 메모이제이션은 fetch request의 GET 메서드에만 해당한다.
  - 그러나 NextJS에서 확장이 되어서 그런지 POST 요청을 하는 fetch도 자동으로 caching 된다고 언급되어 있다.
  - 다만 메서드가 Route Handler 내부에 있는게 아니라면 해당되지 않는다고 한다.
  - 요청을 nextjs api handler로 처리해야 해당 캐싱의 이점을 볼 수 있다고 이해했다.

### Revalidation

- Time-based
  - 일정 시간이 지나면 데이터를 재검증
  - 최신성이 중요하지 않은 경우
  ```tsx
  fetch('https://...', { next: { revalidate: 3600 } })
  ```
- On-demand

  - 양식 제출 등의 이벤트 기반으로 재검증
  - 태그 기반 또는 경로 기반하여 데이터 그룹을 한 번에 재검증
  - 가능한 빨리 최신 데이터가 필요한 경우

  ```tsx
  const res = await fetch('https://...', { next: { tags: ['collection'] } })

  // api route에 해당 태그를 심어두고 revalidate를 할 때 같은 태그에 대한 요청을
  // 한 번에 revalidate 할 수 있다는 것
  ```

  - 이를 위해서 태그와 웬만하면 자체 토큰을 세팅하고, 검증할 필요가 있다.

  ```tsx
  // 토큰과 태그 검증 절차가 추가된 api route 예시
  import { NextRequest, NextResponse } from 'next/server'
  import { revalidateTag } from 'next/cache'

  // e.g a webhook to `your-website.com/api/revalidate?tag=collection&secret=<token>`
  export async function POST(request: NextRequest) {
    const secret = request.nextUrl.searchParams.get('secret')
    const tag = request.nextUrl.searchParams.get('tag')

    if (secret !== process.env.MY_SECRET_TOKEN) {
      return NextResponse.json({ message: 'Invalid secret' }, { status: 401 })
    }

    if (!tag) {
      return NextResponse.json(
        { message: 'Missing tag param' },
        { status: 400 },
      )
    }

    revalidateTag(tag)

    return NextResponse.json({ revalidated: true, now: Date.now() })
  }
  ```

  - 또한 path 기반으로도 해당 동작이 가능하다.

  ```tsx
  import { NextRequest, NextResponse } from 'next/server'
  import { revalidatePath } from 'next/cache'

  export async function POST(request: NextRequest) {
    const path = request.nextUrl.searchParams.get('path')

    if (!path) {
      return NextResponse.json(
        { message: 'Missing path param' },
        { status: 400 },
      )
    }

    revalidatePath(path)

    return NextResponse.json({ revalidated: true, now: Date.now() })
  }
  ```

- 아래와 같이 cache를 아예 처리하지 않거나 하는 커스텀이 가능하다.

```tsx
fetch('https://...', { cache: 'no-store' })
```

## 2. 서버에서 타사 라이브러리 사용

> Next.js is working on an API, `unstable_cache`, for configuring the caching and revalidating behavior of individual third-party requests.

- NextJS에서는 타사 라이브러리의 cache 및 revalidate 동작을 처리하기 위한 API를 개발 중이라고 한다.

### Tanstack Query

tanstack query를 nextjs13 app directory에서 사용하는 데에는 약간의 사전 준비가 요구된다.

아래 링크에서 그 내용을 다루고 있다.

[SSR | TanStack Query Docs](https://tanstack.com/query/v4/docs/react/guides/ssr#using-the-app-directory-in-nextjs-13)

- initialData 방법을 이용하면 API를 요청하고 응답을 page에 전달한 다음 props → initialData 순으로 넣어주어야 한다. props drilling이 발생할 수 있고, 응답이 필요한 query가 여러개인 경우 일일이 넣어주어야 해 세팅이 간단하나 권장하지 않는다.

```tsx
import { dehydrate, Hydrate } from '@tanstack/react-query'
import getQueryClient from './getQueryClient'

export default async function HydratedPosts() {
  const queryClient = getQueryClient()
  await queryClient.prefetchQuery(['posts'], getPosts)
  const dehydratedState = dehydrate(queryClient)

  return (
    <Hydrate state={dehydratedState}>
      <Posts />
    </Hydrate>
  )
}
```

두 번째 방법은 위와 같이 dehydrate와 Hydrate를 사용해 주어야 한다.

queryClient를 싱글톤 인스턴스로써 정의하고, 쿼리를 prefetch하고 이를 dehydrate 하여 page에 dehydrateState로 전달하면 된다.

위와 같이 설정하면 중첩 컴포넌트에서도 prefetch 했던 query key와 같은 key를 사용하면 SSR 시에 데이터가 유지된다.

즉 클라이언트에서 hydrate가 진행될 때 queryClient에서 dehydrate한 데이터를 바탕으로 hydrate를 하는 것이다.

tanstack query에서는 dehydrate를 시킨 다음 dehydrated state로 값을 넘겨주어야 cache로써 세팅이 되고 이를 서버사이드 렌더링에서 반환하여 동작한다.

이를 클라이언트에서도 hydrate할 때 dehydrated 된 query를 찾아 각각 hydrate 시켜준다.

### Axios

위에서 알아 본 내용에 기반하여, axios를 사용하면 nextjs에서 제공하는 cache와 revalidate를 사용하기 까다로워진다.

```tsx
import { cache } from 'react'

export const revalidate = 3600 // revalidate the data at most every hour

export const getItem = cache(async (id: string) => {
  const item = await db.item.findUnique({ id })
  return item
})
```

위 예시처럼 별도의 처리가 요구된다.

# NextJS 13에서 별도의 fetch 라이브러리는 필요 없을 수 있다.

NextJS 처럼 고도화 된 프레임워크에서는 위와 같은 설정에 드는 노력이 과연 필요한가에 대한 물음이 생길 수 밖에 없다.

물론 Infinity Scroll 같은 특정 기능에 대해서 강력한 기능을 제공하는 경우(Tanstack Query)에 대해서 일부 도입을 고려할 수 있다.

fetch 라이브러리가 axios에서 제공하는 default config, interceptor 등의 활용을 위해서는 부가적인 노력이 요구될 수 있으나, 현재 단계에서 각 서드파티 라이브러리가 제공하는 SSR에 대한 지원은 NextJS와 자연스럽게 호환된다고 보기는 힘들 것 같다.

하지만 여전히 Tanstack Query와 RSC를 기반한 NextJS의 역할이 다르기 때문에 그 사용에 충분한 의의가 있다는 의견도 있다.

즉 중요한 점은, 구현하고자 하는 특정 부분에서 어떤 전략이 필요할 지를 사전의 정의한 후 적절한 기술을 도입할 필요가 있다는 것… 그런 점에서 내가 이미 작성한 여러 코드 중에 굳이 axios나 tanstack query를 도입할 필요가 없던 내용이 다수 존재한다는 것이다.

## 참고

[React Query 와 SSR - React Query 라이브러리 코드보며 이해하기](https://velog.io/@eomttt/React-Query-와-SSR)

[Next.js v13 App Router로 제품 만들기: 이제 더 이상 Axios를 쓰지 않기로 했습니다](https://velog.io/@myeongjae-kim/Next.js-v13-App-Router로-제품-만들기-fetch를-다루는-기술)

[You Might Not Need React Query](https://tkdodo.eu/blog/you-might-not-need-react-query)

[next.js에서 react query가 필요할까?](https://xionwcfm.tistory.com/339)

[Data Fetching: Fetching, Caching, and Revalidating](https://nextjs.org/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating)


NextJS13에서 axios와 tanstack query는 유효할까


## Contents

# 다양한 렌더링 방식

대표적으로 SSR과 Static Rendering, CSR을 들 수 있다.

## SSR

![230903-025756](/posts/NextJS는_SPA일까_MPA일까/230903-025756.png)

SSR은 서버 사이드에서 브라우저의 요청 시점에 HTML 파일을 생성하고, 브라우저가 응답을 받기 전에 처리되므로 클라이언트에서 템플릿 작성을 위한 중복 요청이 방지된다.

이후 DOM에 맞는 JS 이벤트 등을 hydration 과정을 통해 처리해주면 된다.

## Static Rendering

![230903-025811](/posts/NextJS는_SPA일까_MPA일까/230903-025811.png)

정적 렌더링은 빌드 타임에 이미 해당하는 HTML 파일을 작성한다. SSR은 요청에 따라 매번 HTML을 서버에서 작성하고 응답하는 과정이 필요하지만, 정적 렌더링은 만들어 둔 파일을 전송하면 되기 때문에 TTFB(Time to First Byte) 시간의 단축이 가능하다.

## CSR

![230903-025825](/posts/NextJS는_SPA일까_MPA일까/230903-025825.png)

CSR은 JS를 전달받고 브라우저에서 직접 페이지를 렌더링한다. 즉, JS 파일을 파싱한 후 데이터 전달이나 템플릿 작성 등 모든 과정이 클라이언트를 기반으로 처리된다.

# SPA와 MPA

![230903-025836](/posts/NextJS는_SPA일까_MPA일까/230903-025836.png)

MPA는 페이지마다 HTML 페이지를 서버에서 받고, SPA는 하나의 HTML을 기반으로 서버에서 JSON 등의 데이터를 요청해 동작한다.

# SPA ≠CSR, MPA ≠ SSR

SPA, MPA는 웹 페이지의 구성 방식, CSR, SSR은 렌더링 방식이다.

즉 대응되는 개념이 아닌, 별개의 개념이다.

# 이것은 SPA인가 MPA인가

NextJS에서 SSR을 사용하면 MPA로 동작한다고 생각했는데 그러면 매번 서버에서 제공하는 HTML로 갈아끼워지겠고… 어떻게 상태를 관리하고 유지하는걸까?

결론적으로 NextJS는 SPA라 하기도 MPA라 하기도 명확하지 않다.

추상적인 개념이지만 PESPA(Progressively Enhanced Single Page App)에 대해 알아보자.

![230903-025855](/posts/NextJS는_SPA일까_MPA일까/230903-025855.png)

SPA에서 챙긴 서버와의 중복 동작 문제 해결과 MPA의 요청/응답 기반 단순한 구조의 장점을 결합한… PESPA는 두 장점을 모두 취하기 위해 제안되었다.

기본적인 컨셉은 서버와 클라이언트 모두에서 동일한 구조를 공유한다는 것이다.

페이지의 데이터를 최신 상태로 유지하기 위해 변형이 발생할 때 PESPA는 페이지의 데이터 유효성을 다시 검사하는 브라우저 동작을 에뮬레이트한다.

즉 전체 페이지를 다시 로드하는 MPA와는 달리 요청과 재검증이 함께 발생한다. 서버에서 변경점을 렌더링하고 클라이언트에서 업데이트 할 수 있는 대화형 구조가 가능키 때문에 코드 중복 문제를 해결할 수 있다.

하지만 pending state나, optimistic UI등을 처리하는 것은 서버에 위치할 수 없으므로 클라이언트에서만 실행되는 일부 코드를 갖게된다.

라우팅 동작에 대해 알아보자.

## MPA

![230903-025910](/posts/NextJS는_SPA일까_MPA일까/230903-025910.png)

MPA는 기본적으로 요청에 따른 서버 렌더링 결과를 클라이언트에서 HTML를 새로 렌더링하여 처리한다.

전통적인 MPA에서는 애초에 client-side Navigation에 대해서 다룰 수 없다.

## SPA

![230903-025924](/posts/NextJS는_SPA일까_MPA일까/230903-025924.png)

prevent default하고, JS를 통해 URL을 업데이트한다.

클라이언트 라우팅 로직에서 업데이트 요구사항을 결정하고 데이터 요청을 하는 동안 UI는 대기.

서버에서 라우팅 로직을 통해 요청한 데이터를 가져와 클라이언트에 전달한다.

클라이언트에서 데이터를 받아 해당 데이터를 UI 업데이트에 사용한다.

## PESPA

![230903-025935](/posts/NextJS는_SPA일까_MPA일까/230903-025935.png)

SPA와 같이 prevent default.

라우터는 새로운 요청에 대한 데이터와 UI를 한 번에 결정한다.

데이터를 가져와 UI에 반영한다.

# NextJS

CSR과 SSR, SSG 등의 다양한 전략을 개발자가 적절히 선택하게 해 주는 Remix와 NextJS 등의 도구는 PESPA에서 server와 client 간 동일한 구조를 이어주는 브릿지 역할을 제공해준다고 할 수 있다.

NextJS는 서버에서 페이지를 렌더링하고 클라이언트에서 구성 요소만 hydration함에도 불구하고 페이지가 로드되면 여전히 SPA로 작동한다.

첫 번째 렌더링이 서버에서 이루어지지만 첫 페이지에서의 라우팅 및 탐색이 클라이언트에서 발생한다. 즉 SSR과 CSR의 장점을 섞은 방식이라 할 수 있겠다.

첫 요청 페이지를 SPA 삼아서 CSR하기 때문에 전역 상태와 같은 기능을 사용할 수 있다.

NextJS에서는 Link 태그를 통해 prefetch를 하여 페이지를 미리 로드해둔다.

구체적으로 말하자면 이동할 가능성이 있는 페이지는 미리 가져오는 작업을 하고, 그런 경우 HTML을 새로 받아와 갈아끼우는게 아닌 미리 로드된 데이터를 바로 랜더링하여 보여주는 것이다.

덕분에 SPA처럼 빠른 라우팅 전환이 가능하면서도, SSR에서 제공하는 준비된 DOM을 얻을 수 있는 것이다(React와 같이 JS를 hydration하는 과정이 일어난다).

로드 시 SSR 방식의 페이지는 JS를 로딩하고, SSG 방식의 페이지는 HTML이 아닌 JSON파일을 돌려준다.

![230903-025946](/posts/NextJS는_SPA일까_MPA일까/230903-025946.png)

[Rendering on the Web](https://web.dev/rendering-on-the-web/)

[NextJS - SPA or MPA?](https://www.code-insights.dev/posts/nextjs-spa-or-mpa)

[The Web’s Next Transition](https://www.epicweb.dev/the-webs-next-transition)

[next.js의 SSG 제대로 이해하고 사용하기 | parkgang.log](https://parkgang.github.io/blog/2021/09/07/lets-properly-understand-and-use-the-ssg-of-nextjs/)

[SPA로 SSR 구현하기](https://taero.blog/posts/SPA-with-SSR)

[Next.js의 렌더링 과정(Hydrate) 알아보기](https://www.howdy-mj.me/next/hydrate)

[The Web’s Next Transition(웹 애플리케이션 아키텍처의 미래)](https://itchallenger.tistory.com/750)

[Next.js 13 master course - Static / Dynamic Rendering](https://velog.io/@jay/Next.js-13-master-course-Static-Dynamic-Rendering)

[Next.js is an SPA](https://www.reddit.com/r/nextjs/comments/11qotnt/nextjs_is_an_spa/)

[Web: Next.js Link와 Prefetch 과정 파헤쳐보기](https://medium.com/hcleedev/web-next-js-link와-prefetch-과정-파헤쳐보기-44e22ace13e7)


NextJS는 SPA일까 MPA일까


## Contents

![230711-172358](/posts/NextJS13과_NextAuth.js를_활용한_OAuth_도입기/230711-172358.png)

# 개요

요즘 서비스는 전통적인 로그인 방식을 아예 제하고 OAuth만 사용해서 가입, 인증을 구현하는 경우가 더러 있다.

이번에 새로 Blankit 프로젝트를 진행하면서 기획 단계에서 이메일 로그인을 과감히 삭제(예상되는 유저층이 모두 카카오, 구글, 네이버 중 하나 이상 가입 돼 있을 것이므로)하기로 됐다.

마침 프론트 웹을 NextJS13을 사용하기로 한 만큼 OAuth도 편하게 구현할 수 있는 NextAuth.js를 사용하기로 했다.

- NextAuth.js란?
  [NextAuth.js](https://next-auth.js.org/) (그런데 와중에 [Auth.js](https://authjs.dev/)로 이름과 페이지가 업데이트됐다)
  _~~도와줘 ChatGPT!~~_
  ![230711-172434](/posts/NextJS13과_NextAuth.js를_활용한_OAuth_도입기/230711-172434.png)

# 환경

![230711-172417](/posts/NextJS13과_NextAuth.js를_활용한_OAuth_도입기/230711-172417.png)

전체적인 구조는 간단하다.

Vercel로 배포된 NextJS서버와 AWS 상의 Spring 서버 그리고 DB.

이에 추가로 각 OAuth 서비스 운영자가 제공하는 Provider 서버가 있을 것이다.

# 과정

## 첫 번째 시도

### 구상

초기에는 찾아본 자료를 통해 일반적인 경우의 OAuth 로그인을 구현하고자 했다.

![230711-172449](/posts/NextJS13과_NextAuth.js를_활용한_OAuth_도입기/230711-172449.png)

위 그림과 같이

1. 클라이언트에서 NextAuth를 통해 서버(Next백엔드) - Provider 서버 간 통신 과정을 통해 user 정보와 auth server access token을 발급받는다.
2. 백엔드(스프링) 서버에 로그인 요청을 하면서 auth server로 부터 발급받은 access token을 보낸다.
3. 클라이언트는 백엔드(스프링) 서버로부터 유저 정보 및 api 요청에 사용될 token을 발급받는다.

의 과정이었다.

### 문제

1. Auth Service Provider와의 요청 시에는 NextJS 자체 백엔드 서버를 거쳐서 발급받고 이후에는 그 정보를 클라이언트에서 스프링 백엔드 서버에 요청한다. 이 과정이 퍽 직관적이지 못하고, 꽤 오버헤드가 많이 발생한다고 생각한다.
2. (auth provider로 부터 받은) access token을 로그인 요청시 spring 서버에 담아 보낸다. 이를 통해서 유저 정보를 spring 서버에서 auth provider에 재요청해서 DB에 저장하거나 활용할 수 있는데, 중복적으로 auth를 요청하는 상황이 불필요하며, 구현하기 복잡하다.
3. 제일 중요한 점은 NextJS backend에 적응이 안된 내가 이를 번갈아 가며 사용하는 것에 어려움을 느끼고 있다.

## 두 번째 시도

### 구상

NextAuth.js에서 권장하는 백엔드와의 연결 및 아키텍쳐가 있었다. 그런데 NextJS13 관련한 자료도 흔치 않은데 이를 응용해 데이터베이스 어뎁터를 생성하는게 녹록치 않아 처음엔 넘어갔었다.

팀원 분의 큰 도움으로 대략적인 문서의 구현 및 세부 내용을 배울 수 있었다.

[문서](https://next-auth.js.org/v3/tutorials/creating-a-database-adapter)

일단 nextAuth 자체가 nextJS api 디렉터리에 `[...nextAuth].js` 명의 파일을 생성해 작성한 `authOptions`을 기반으로 작동한다.

nextAuth.js의 장점이 이 과정에서 간단한 설정만으로 가입, 로그인 로직을 직접 구현할 필요없이 추상화 된 메서드를 통해 유저 정보와 세션, 토큰을 얻을 수 있다는 것이다.

하지만 따로 백엔드 서버(우리의 spring 서버에 해당하는)를 통해 조금 더 커스텀한 로직을 구현하길 원하는 유저를 위해 nextAuth.js에서는 adapter를 구현해 지정해줄 수 있다.

### 구현

공식 document에서는 다음과 같은 예시를 제공한다.

```jsx
export default function YourAdapter (config, options = {}) {
  return {
    async getAdapter (appOptions) {
      async createUser (profile) {
        return null
      },
      async getUser (id) {
        return null
      },
      async getUserByEmail (email) {
        return null
      },
      async getUserByProviderAccountId (
        providerId,
        providerAccountId
      ) {
        return null
      },
      async updateUser (user) {
        return null
      },
      async deleteUser (userId) {
        return null
      },
      async linkAccount (
        userId,
        providerId,
        providerType,
        providerAccountId,
        refreshToken,
        accessToken,
        accessTokenExpires
      ) {
        return null
      },
      async unlinkAccount (
        userId,
        providerId,
        providerAccountId
      ) {
        return null
      },
      async createSession (user) {
        return null
      },
      async getSession (sessionToken) {
        return null
      },
      async updateSession (
        session,
        force
      ) {
        return null
      },
      async deleteSession (sessionToken) {
        return null
      },
      async createVerificationRequest (
        identifier,
        url,
        token,
        secret,
        provider
      ) {
        return null
      },
      async getVerificationRequest (
        identifier,
        token,
        secret,
        provider
      ) {
        return null
      },
      async deleteVerificationRequest (
        identifier,
        token,
        secret,
        provider
      ) {
        return null
      }
    }
  }
}
```

이걸 보고 왜 처음에 넘어갔냐면, 예시만 있고 설명이 거의 없다시피했다. 문서가 그리 친절하진 않고… 구글링해도 사례를 찾기가 힘들다.

이후 팀원 분의 도움 덕에 다음과 같은 과정을 알 수 있었다.

먼저 adapter를 넘겨주면, 내부의 함수가 정해진 플로우대로 동작한다. 내부의 구현을 하나하나 정해줄 필요가 없다.

## 미가입 상태 로그인

1. `getUserByAccount`를 호출하여 로그인한 `Account`가 reference하는 `User`가 있는지 확인 후 리턴
2. 만약 없다면 `getUserByEmail` 호출하여 동일한 이메일로 가입된 `User`가 있는지 확인 후 리턴
   1. 만약 있다면 다른 제공업체로 가입한 것이므로 로그인 진행 멈추고 `…/signin?error=OAuthAccountNotLinked`로 이동됨 사용자에게 다른 로그인 방법으로 시도 하라는 메시지 띄어주면됨 (ex. google로 가입한 상태에서 같은 이메일인 github 로그인시 발생)
3. `createUser` 호출하여 `User` 스키마에 데이터 등록 시키고 등록한 유저 정보리턴
4. `linkAccount` 호출하여 위에 생성한 `User`와 `Account`를 데이터베이스상에서 연결

## 가입상태 로그인

1. `getUserByAccount`를 호출하여 로그인한 `Account`가 reference하는 `User`가 있는지 확인 후 리턴 (여기서 리턴된 유저의 정보가 아래의 콜백에서 사용됨)
2. 존재한다면 AuthOptions의 callbacks에 `session`함수 호출됨

   1에서 리턴한 유저 id가 `token.sub`에 담겨있는데 이를 활용해 getUserById와 같은 함수를 만들어 호출시킨후 client 에서 사용할 데이터를 담아서 리턴하면됨

이제 여기서 spring backend에서 수행할 몇 가지 api 구현을 요청하면 된다.

사전적으로 백엔드와 필요한 DB 스키마에 대한 합의가 선행되어야 한다.

NextAuth.js의 adapter 동작에 적합한 DB 모델은 마찬가지로 document에서 제안해주는 스키마를 따르도록 하자.

![230711-172510](/posts/NextJS13과_NextAuth.js를_활용한_OAuth_도입기/230711-172510.png)

Account 스키마는 Auth Provider로부터 받는 정보들을 NextAuth에서 반환해준 정보이고, User 스키마에 기본적인 유저 정보 및 서비스에서 추가로 필요한 필드를 추가해주거나 빼주면 된다.

우리 서비스의 경우로 예를 들면 경력, 업종 등을 User에 추가해주면 될 것이다.

Adapter를 통해 spring 서버에 요청할 API는

- User 생성
- User와 Account의 link
- ID를 통한 User 조회
- Email을 통한 User 조회
- Account를 통한 User 조회

가 있다.

중요한 점은 api 요청 시의 token을 어떻게 처리하냐인데, nextJS의 백엔드와 spring 간에 합의된 secret 키를 정의해두고 user next 백엔드 내부에서 user 인증이 통과된 경우에만 요청 가능하도록 했다.

![230711-172519](/posts/NextJS13과_NextAuth.js를_활용한_OAuth_도입기/230711-172519.png)

결과적으로 위와 같이 로그인 처리와 api 요청 과정을 조금 더 간소화할 수 있다.

# 결론

nextJS 13의 api 폴더와 nextAuth.js에서 제공하는 강력한 auth 관리를 통해 쉽게 OAuth 로그인을 구현할 수 있다.

하지만 여러 상황에 따라 원하는 방식으로 커스텀화하는 과정이 공식 문서의 불친절함(에 더한 나의 부족한 영어실력 덕분에) 쉽지만은 않게 느껴졌다.

여러 문서와 동료분의 도움으로 로그인의 세부 과정(다른 플랫폼으로 가입한 동일 메일 처리 등)을 커스텀할 수 있었다.

앞으로 수정사항이 생길 것 같은데, 정리해서 업데이트 해야겠다.


NextJS

NextJS13에서 axios와 tanstack query는 유효할까

NextJS는 SPA일까 MPA일까

NextJS13과 NextAuth.js를 활용한 OAuth 도입기