Apollo GraphQL 및 SSR 사용

이것은 SSR(Server Side Rendering)을 활용하는 Next.js(typescript) 프런트 엔드가 있는 golang 백엔드에 JWT 인증 흐름을 추가하는 방법에 대한 짧은 게시물입니다.
사용자 경험을 용이하게 하기 위해 프런트 엔드에 대한 단일 사인온 인증 흐름에 Next Auth를 활용하는 동안 나는 graphql을 사용하여 golang에서 호스팅되는 백엔드의 JWT 인증 흐름에 헤더를 전달할 수 없기 때문에 피클에 빠졌습니다.
브라우저에서 세션(또는 로컬) 저장소에 액세스하여 요청 헤더를 통해 JWT를 전달할 수 없기 때문에 SSR을 사용할 때 문제의 일부가 발생합니다. 따라서 약간의 창의력을 발휘하고 온라인에서 다른 예를 샅샅이 뒤져 apollo 클라이언트 내보내기에 대한 조정을 생각해 냈습니다.
처음에는 아래 코드를 통해 apollo 클라이언트를 만들고 useSession, sessionStorage, localStorage 등에서 JWT 토큰에 액세스하려고 시도했습니다.

import { ApolloClient, createHttpLink, InMemoryCache } from "@apollo/client";
 const authLink = setContext(async (_, { headers }) => {
        return {
            headers: {
                ...headers,
                Authorization: context ? context : "",
            }
        }
    });

const client = new ApolloClient({
        link: authLink.concat(httpLink),
        ssrMode: typeof window === 'undefined',
        cache: new InMemoryCache()
    });
}

export default client;

콜백 문제가 발생하지 않고는 여전히 애플리케이션과 관련된 모든 종류의 컨텍스트에 액세스할 수 없다는 것을 알았습니다. 따라서 클라이언트가 아래에서 비동기적으로 생성되고 반환됩니다.

import { ApolloClient, createHttpLink, InMemoryCache } from "@apollo/client";
import { setContext } from "@apollo/client/link/context";

const httpLink = createHttpLink({
    uri: process.env.GRAPHQL_URI,
    credentials: "include"
})
const createClient = async (context: any) => {
    console.log('client context', context)
    const authLink = setContext(async (_, { headers }) => {
        return {
            headers: {
                ...headers,
                Authorization: context ? context : "",
            }
        }
    });
    return new ApolloClient({
        link: authLink.concat(httpLink),
        ssrMode: typeof window === 'undefined',
        cache: new InMemoryCache()
    });
}

export default createClient;

이제 아래와 같이 세션 데이터를 전달(JWT 쿠키 매개변수 설정을 통해)하여 SSR 호출에서 세션 데이터에 액세스할 수 있습니다.

 const client = await createClient(sessionData?.Authorization);

그 이후에는 클라이언트 측 세션 저장소 또는 로컬 저장소를 사용하는 것과 유사하게 JWT를 전달할 수 있습니다.
이것이 백엔드/프런트엔드 API와 관련하여 우려 사항을 분리하고 자체 인증 흐름을 유지하려는 동료 친구들에게 도움이 되기를 바랍니다.