23.07.02~23.07.09

업무

1. 채팅방 내 로그인 기능 배포

지난주에 개발한, 보호자가 채팅방에 접근했을 때, 소셜 로그인 및 회원가입 유도하는 기능을 배포했다.

 

배포 전 release환경에서 내부 통합 테스트를 진행했는데,

react-native-webview에서 페이지 route 발생 시 초기 세팅한 source의 header 속성이 유실되는 이슈가 있었다.

 

https://github.com/react-native-webview/react-native-webview/blob/master/docs/Guide.md#Setting-Custom-Headers

공식문서에 (친절한) 설명 및 예제 코드가 있어, 수정 자체는 손쉽게 할 수 있었다.

 

하지만 위 방법은...

웹뷰 컴포넌트 내에서 해당 페이지 uri를 state로 관리하면서

react-native-webview의 onShouldStartLoadWithRequest 속성을 통해

요청된 페이지지의 uri가 해당 state와 다를 경우(페이지 이동이 발생했을 경우) 해당 페이지 load를 멈추고

관리하던 uri state를 set해주면서 컴포넌트를 re-render하는 방식으로 구현되어 있다.

 

기존 컴포넌트에서도 해당 페이지 uri를 관리하던 state가 있어 쉽게 붙일 수 있었지만...

1) 불필요한 state 추가 2) 최초 load 중지 라는 비효율이 발생한다. → 굳이 이럴 필요가 있을까? 하는 의문.

 

대신 webview 내에서 route 시키기보다는 postMessage 이벤트를 발생시켜,

inApp 내부적으로 page navigation이 발생하게 만드는 것도 좋을 방법일 수 있겠다...는 생각이 들었다.

 

2. 미용샵 랜딩 페이지 SSG시 DB 직접 조회

오랜 숙원 사업...

지난주, 미용샵 랜딩 페이지 생성 방식은 SSR에서 SSG로 변경했다.

각 랜딩 페이지들은 미용샵 링크를 고유하게 갖고 있었기 때문에, getStaticPaths를 통해 각 dynamic path들을 미리 지정해줘야 했다.

 

즉... 어떻게 해서든 현재까지 생성된 미용샵 링크 id를 조회해와야 했는데

당장 이를 위한 추가 api를 개발할 필요는 없다고 판단해 → 지금까지 DB에 존재하는 링크 id를 하드코딩해 작성했었다(!!!)

 

링크 생성이 제한되어 있는 지금은 별 문제가 없지만, 추후에도 개발자가 직접 하드코딩할 순 없기 때문에

SSG시 DB에 직접 접근해, SQL문을 통해 원하는 데이터(링크 id 목록)를 조회하도록 수정했다.

 

const pgp = require("pg-promise")();

// PostgreSQL 연결 문자열
const connectionStr = `postgres://${USERNAME}:${PASSWORD}@${HOST}:${PORT}/${process.env.DATABASE}`;

// pg-promise 인스턴스 생성
const db = pgp(connectionStr);

export default db;

 

pg-promise를 통해 PostgreSQL DBMS와 손쉽게 연결할 수 있었고,

export async function getStaticPaths() {
  	try {
		const ids: { id: number }[] = await db.any(
      		"SELECT id FROM data"
    	);
	// ... //
}

생성된 인스턴스에 작성한 SQL문을 통해 원하는 데이터를 조회할 수 있다.

즉 앞으로는... 단순한 GET api 정도는 추가적인 server api 없이 해당 데이터에 접근할 수 있는 것!

 

개선사항으로는

1) pg-promise로 생성한 db 인스턴스의 메서드들에 SQL문을 그냥 문자열 형태로 작성

→ 각 명령어나 테이블명 작성 시 오타 수정이나 자동완성을 활용할 수 없는데, 이를 개선할 수 있지 않을까?

 

2) 복잡한 SQL문 추가 (1과 유사)

→ JOIN문, WHERE절이 추가될 경우, 해당 문자열은 점점점 길고 알아보기 힘들어질 텐데... 이 역시 좋지 않은 개발 경험이 될 테다.

 

3) Module not found : Can't resolve 'fs' (Client 측 DB 접근)

연결 상태를 확인하기 위해, client 측 코드에서 생성된 db 인스턴스를 호출했는데, 위와 같은 에러가 발생했다.

 

당최 무엇인지 살펴보니...

fs 모듈은 Node.js의 전용 내장 모듈이며, 파일 시스템에 접근하는 기능을 제공하기 때문에 브라우저에서는 사용할 수 없다!

즉 서버 환경에서만 사용 가능하므로... SSR이나 SSG에서만 해당 인스턴스에 접근할 수 있는 것.

 

그렇다면 클라이언트 측에서 DB에 접근하기 위해서는 (결국) BE api 개발이 필요한 것일까?!

→ No! 이를 위해 Next js의 api routes를 사용할 수 있다. 

https://nextjs.org/docs/pages/building-your-application/routing/api-routes

Routing: API Routes | Next.js

작성된 end point에 요청해 서버 측에서 필요한 작업을 수행한 후, 클라이언트 측에서는 필요한 데이터를 가져올 수 있겠다.

(처음 next js를 사용할 때, 왜 이런 기능이 필요한 걸까... 했었는데, 이제야 몸소 알게 되었다. 하하!)

 

3. 웹 버전 미용샵 가입 기능 추가 개발

웹 버전 내 가입 페이지를 FE 측 로직만 작성하고, BE api 테스트를 진행하지 않은 채로 넘어갔었는데...

이번 스프린트 때 여유가 좀 있어 이를 마무리지었다.

 

4. 재예약 유도 알림톡 모듈 작성 (취소)

만든 기능이 배포 당일 보류된 심정이란

앱 내 각기 다른 템플릿으로 카카오 알림톡을 발송하는 기능이 있다.

해댱 알림톡은 message를 발송하는 기능의 하위 기능이며,

각 알림톡 별로 필요한 공통 로직(변수 작성 여부, 승인 여부, 템플릿 아이디 체크 등)이 존재하면서

동시에 각 템플릿 별로 필요한 추가 로직(리마인더 템플릿은 날짜 체크가 필요하다던지)도 존재하는 상황이었다.

 

이 전까지는 각 함수 및 발송 로직이 발송하는 view단 로직에 무작정 섞여 작성되어 있었는데...

이를 공통 모듈 Class로 작성할 수 있겠다는 생각을 이전부터 해왔었다.

 

때 마침 이번 재예약 유도 알림톡이라는 추가 메시지 발송 기능 요구 사항이 생겼었고,

이를 위해 1) 메시지 생성 모듈 2) 템플릿 메시지 생성 모듈 3) 재예약 유도 템플릿 메시지 생성 모듈 을 구현했다.

 

비록 기획상의 이유로 잠시 보류됬지만...

추가적인 템플릿 메시지 생성이나, 변경 사항에서 좀 더 자유로운 모듈들이 생겨 든든했달까!