• 페이지 요청 [파란색]
  • FE가 Server(Backend)에게 필요한 페이지 요청
  • Server(Backend)는 요청한 request header에 있는 사용자 세션 정보를 파악 후 서버사이드 렌더링된 페이지를 FE에 전달.(그 페이지 안에는 클라이언트 컴포넌트가 있음)
• API 라우트 요청 [노란색]
  • FE는 Server에서 전달 받은 서버사이드 페이지 안에 있는 클라이언트 개별 페이지 상의 api를 Server(Backend)에게 요청
    • 팔로잉하고 있는 사용자 목록, 포스트
  • 라우트 핸들러에서는 각각의 요청에 한에서 새니티에서 정보를 받아와 클라이언트에게 보내줌.

코드상 정리

1st

• 코드상으로는 app 폴더 안의 특정한 경로안에 페이지만 만들어놓으면, 알아서 요청이 들어감

• 서버 세션을 사용하고 있기 때문에 해당 페이지의 경우 서버사이드 렌더링이 되었음.

  const sessiont = await getServerSeeiont(authOptions);
  

2nd

• 각각의 컴포넌트 내에서는

  // 클라이언트 컴포넌트임을 명시.
  'use client'
  
  // 내부적으로는 SWR을 사용, 즉, 클라이언트 컴포넌트가 렌더링되자 마자 해당 api경로로 api요청이 들어감.
  const { data, isLoading: loading, error } = useSWR<DetailUser>('/api/me'); 
  

3th

• app폴더내, api내 해당폴더(ex, me) 내의 route.ts에서 해당 요청을 처리.

• route에 있는 코드들은 서버에서 동작하며, 각각의 라우트들은 독립적인 라우트 핸들러.

• route에서 사용자가 로그인을 했는지 정확한 정보를 확인한 후 헤더에 들은 로그인 정보를 토대로 해서 그 해당하는 사용하는 사용자의 자세한 정보를 FE에게 보내주었음.

  export async function GET(request: Request) {
    const session = await getServerSession(authOptions);
    const user = session?.user;
  
    if (!user) {
      return new Response('Authentication Error', { status: 401 });
    }
  
    return getUserByUsername(user.username).then((data) =>
      NextResponse.json(data),
    );
  }
  
  

• 또한 sanity에 접근해 데이터를 읽어오는 코드의 경우 라우트 핸들러에 작성한게 아니라 따로 모듈화하여, service폴더에 작성해서 사용