신입 프론트 개발자의 온보딩 교육 후기 🌱 (2)

팀민트 기술블로그·2023년 3월 31일

개발자 온보딩

신입 프론트 개발자의 온보딩 교육 후기

목록 보기

2/2

안녕하세요! 팀민트 Tech팀의 혜진입니다.

1편에서는 온보딩 프로젝트의 전반적인 절차를 알려드렸는데요.
2편에서는 프로젝트를 진행하면서 느낀 점을 소개해드리려고 합니다.

프로젝트 진행

1. 새로운 기술을 사용하며 느낀 점

GraphQL

GraphQL을 사용해보니 공식 문서에서 설명한
over-fetching 과 under-fetching 을 방지한다는 점에서 효율적이라고 느꼈습니다.

over-fetcing : 사용하지 않는 데이터까지 가져오는 것
under-fetching : 하나의 endpoint 요청으로는 충분한 데이터를 받지 못하는 것

예를 들어, 채팅 목록을 보여주고 싶을 때
채팅의 정보와 유저의 닉네임 을 함께 보여줘야 합니다.

만약 API의 endpoint가 채팅 정보 / 유저 정보
2개로 나눠져 있다고 하면, 하나의 endpoint로
필요한 정보를 받아올 수 없어 API를 2번 호출할 수 밖에 없는데요.

GraphQL로 under-fetching 문제가 발생했을 때
하나의 쿼리로 채팅 정보 / 유저 닉네임까지
함께 가져올 수 있어서 편했습니다.

query chat() {
  forest_chat() {
    id
    message
    create_at
    user {
      nickname // 유저의 닉네임
    }
  }
}

GraphQL code generator

더불어 팀에서는 GraphQL code generator를 사용해 생산성을 높이고 있었는데요.
code generator는 GraphQL 스키마를 읽고 type, operations 등을 생성 해주는 툴입니다.

예시
제가 아래처럼 쿼리를 작성하고
npm run codegen 을 실행한다면

type, hook 등이 자동으로 생성되는 것이죠!
별도로 선언하지 않아도 돼서 편했습니다.

Hasura

두 번째로 소개할 기술 스택은 Hasura입니다.

Hasura는 GraphQL API를 자동 생성해주는 GraphQL 엔진입니다. 백엔드 개발자가 해야했던 DB CRUD를 대신 구현 해준다는 장점이 있는데요. 클라이언트가 GraphQL을 통해 요청을 하면 Hasura는 SQL문으로 바꿔서 연결된 Database로부터 직접 데이터를 가져와서 return 해줍니다.

이러한 장점 덕분에 프론트엔드 개발자가 API 완성을 기다리지 않고 바로 개발을 하게 해주는 생산적인 기술이라는 생각이 들었습니다.

실제로 Hasura 콘솔에 접속 해보니 제가 원하는 모든 API가 다 만들어져 있었습니다 (신세계 🫢)

채팅을 여러 개 가져오는 것도, 특정 채팅만 가져오는 것도 모두 미리 구현되어 있어 개발 속도가 단축되는 효과가 있었습니다.

또한 테이블별로 role과 권한을 설정해서
관리자와 일반 유저가 할 수 있는 행동을 제한할 수 있다는 장점이 있었습니다.

예를 들어, 유저가 채팅 삭제와 편집을 할 수 없게 하려면 chat 테이블의 permission 에서 update와 delete 를 X로 설정하기만 하면 돼서 굉장히 편했습니다 👏

2. 기억에 남는 점

Next.js에서 ip 제한하기

프로젝트를 진행하면서 가장 기억에 남는 점은 ip 제한 구현이었습니다.

주어진 미션은 채팅 목록을 볼 수 있는 페이지에 접속할 때 사내 ip가 아닐 경우 /404 페이지로 리다이렉트 시키는 것이였는데요. Next.js의 middleware를 사용해서 /chats 페이지에 접근할 때 마다 request header의 ip와 사내 ip가 일치 하는지 비교하도록 했습니다.

이 때 팀원 분께서 해주신 조언이 도움이 많이 됐는데요. ip를 가져올 때 x-forwarded-for 를 사용하라는 것이였습니다.

x-forwarded-for (MDN)

x-forwarded-for (XFF) 헤더는 HTTP 프록시나 로드 밸런서를 통해 웹 서버에 접속하는 클라이언트의 원 IP 주소를 식별하는 사실상의 표준 헤더인데요.

웹 서버는 앞에 로드 밸런서, 프록시 서버 등의 장비가 있을 경우 실제 클라이언트 IP가 아닌 앞단에 있는 장비 IP에서 접속한 것으로 인식한다고 합니다.

클라이언트 IP → Proxy 서버 및 장비 → 웹 서버

x-forwarded-for는 콤마로 client와 proxy ip를 구분하는데요. 이를 통해 실제로 요청한 클라이언트의 ip를 알 수 있다고 합니다.

x-forwarded-for : <client>, <proxy1>, <proxy2>

조언을 바탕으로 아래처럼 ip 제한 코드를 작성할 수 있었습니다. 짧은 코드지만
왜 써야 하는지 이유를 알 수 있어서 기억에 남았습니다.

export function middleware(req: NextRequest) {
  if (req.headers.get("x-forwarded-for") !== "사내 IP")
    return NextResponse.redirect(new URL("/404", req.url));
  return NextResponse.next();
}

export const config = {
  matcher: ["/chats"],
};