SSG와 SSR의 시행착오

camel·2023년 8월 5일

Q&A SSR next ssg 개발 공부 프로젝트

Project Refactoring

목록 보기

5/6

기존 프로젝트를 진행하면서 SSG를 쓰려고 하였다.
이유는 첫번째로는 금액이었고,
다음으로 데이터 업데이트를 자주할 필요가 없다고 생각하였다.

그래서 총 2개 화면에서 SSG를 구현하였는데

게임 화면과 랭킹 화면이었다.

QA 진행

백엔드 분과 같이 QA를 진행하였는데,
이상형 월드컵을 만들고 다시 캐릭터를 추가하였는데 그것이 반영이 안되는 이슈를 이야기하였다.
정리해서 적어보자면,

나의 생각
유저가 업데이트를 하고 한번보고 바로 나갈 것이라고 생각하였다.
그래서 한번만 마운트 시키고 재접속해도 유지 시키는 방안으로 SSG를 고려하였다.
QA
백엔드 분이 직접 사용해보면서 이 부분이 부자연스럽다고 느꼈다.
본인이 업데이트한 이상형 월드컵을 직접하면서 확인하고 싶고, 랭킹 부분에 있어서 주기적으로 본인이 좋아하는 이상형 월드컵을 확인할 수도 있다는 이슈였다.

그래서 고민 끝에 SSR로 바꾸기로 하였다.

아직 나는 서버에 얼만큼 비용이 드는지 계산이 안되어서 최대한 아껴보자는 느낌이었는데, 이번을 계기로 생각해보니 SSR로 바꾼다고 극적인 금액이 차이날 것 같진 않았다.
왜냐하면 우리는 유저수가 적은 작은 서비스이기 때문이다.

성능적인 차이는?

이제 SSR로 바꾸려고 하는데 문득 성능 차이가 궁금하였다.
예상대로라면 둘다 들어올때 미리 만들기때문에 마운트 할 때는 차이가 안날 것이다.
(마운트 이후에는 SSG가 좋을 것이다.)

먼저 로직부터 보자
랭킹과 인게임 로직의 큰 차이가 없어서
비교적 간단한 랭킹 로직을 가져왔다.

export const getStaticPaths: GetStaticPaths = async () => {
  return {
    paths: [],
    fallback: "blocking",
  };
};
export const getStaticProps: GetStaticProps = async ({ params }) => {
  const worldcupId = params?.id as string;
  //worldcups/1

  return { props: { worldcupId } };
};

blocking 쓴 이유는 미리 안만들어놓고 들어올 때마다 만들 생각이었다.
다시 생각해보면 맨앞 5개정도는 미리 만들어도 괜찮았을 것 같다.

export const getServerSideProps: GetServerSideProps = async ({
	params
}) => {
	const worldcupId = params?.id as string; // 월드컵 ID를 받습니다.

	// 데이터 요청이 성공한 경우, worldcupId를 props로 반환합니다.
	return { props: { worldcupId } };
};