만들고 싶은 애플리케이션이 생겨서 React Native로 만들어보려고 한다.

다행히도 노마드코더님이 최근에 리액트 네이티브의 무료 강의를 업데이트 해주셔서 시작은 이 강의를 참고하기로 했다.

앱을 만드는 건 처음이라서 강의내용이 새로웠다.

리액트의 친척이라서 문법면에서는 배우는데 어려움이 없다.

원래 앱을 개발하려면 자바 등 앱 개발 환경을 구축해야 하지만, Expo라는 도구로 개발환경을 따로 구축하지 않아도 개발이 가능하다고 한다.

내 휴대폰과 연동해서 실시간으로 결과를 확인할 수도 있어서 편하다.

리액트 네이티브는 리액트의 친척이지만 브라우저로 돌아가는게 아니기 때문에, 기존의 HTML문법은 쓰지 않는다.

하지만 컴포넌트 개념은 그대로 남아있어서, 리액트 네이티브의 컴포넌트명만 익숙해지면 빠르게 적응할 수 있겠다. (컨테이너를 만들 때는 div 대신 View라는 컴포넌트를 쓴다.)

리액트 네이티브는 원래 다양한 컴포넌트를 자체적으로 가지고 있었지만, 빠르고 유지를 쉽게 하기 위해서 현재는 중요한 기능만 남겼다고 한다.

대신 유저들이 만든 컴포넌트, API들을 쓴다고 한다.

HTML, CSS와 비슷한 부분도 있고 다른 부분도 있어서 배우는게 재미있다.

컴포넌트나 옵션중에 편리한 기능이 많아서 좋다. ScrollView만 해도 가로로 정렬해주는 horizontal, 컨텐츠들을 자동으로 페이징해주는 pagingEnabled(이게 제일 놀라웠다), showsHorizontalScrollIndicator 같은 옵션들이 있어서 흥미롭다.

ScrollView는 그냥 style이 아닌 contentContainerStyle을 써야한다고 한다.

오늘은 '여행 스타일' 옵션에 따라 코스를 걸러주는 코드를 짰다.

사용자가 지역추천을 요구했을 때, 지역을 어떻게 골라줄지도 결정되었다.

출발지역은 어차피 큰 지역을 고르기 때문에, 그 지역으로 부터 200km 이내에 있는 지역들의 코스로 걸러주기로 했다.

팀원들과 이야기하면서 하니까 정신이 조금 맑아졌다.

인간은 사회적인 동물이다.

Redis 때문인지는 모르겠지만, 포트 오류가 뜬다.

내일은 이것을 먼저 해결하고, 랜덤 알고리즘을 완성하고싶다.

오늘은 관광지의 디테일 정보를 보내주는 API를 만들었다.

뿌듯했다.

사용자가 선택할 수 있는 옵션을 정리하고 코스를 뽑는 알고리즘도 정리했다.

생각보다 난관이 많다.

다 만들고 나서 성능을 개선해야 할 지 지금 단계에서 생각해서 만들어야 할 지 고민된다.

일단 구현부터 시켜야겠다.

오늘은 기대했던 더 수어사이드 스쿼드를 봤다.

스토리는 별로였고, 연출이나 CG가 좋았다.

프로젝트에 대해 많은 생각을 했다.

어제 정해진 기능들의 수정사항들을 고치고 서버의 코드들을 병합했다.

서버쪽 DB에다가 관광지 데이터들도 전부 채워넣었다.

오늘은 오전에 쭉 팀 회의를 했다.

첫 배포가 끝나고 진짜 서비스 배포까지 2주가 남은 시점에서 방향성을 어떻게 잡을 지 이야기를 했다.

저녁에 진행된 디자이너분들까지 참석하신 회의에서 최종적으로 어떤 기능이 들어갈지 정해졌고, API를 본격적으로 수정하기 시작했다.

어제 DB설계를 완료했고, 프론트분들의 API키까지 전부 얻어서 마음껏 API를 수정하고 테스트할 수 있었다. 너무 좋다.

내일은 기존의 API를 수정하고, 코스저장 기능까지 완성하는 것이 목표이다.

오늘 다른 조의 Node.js 분들이 놀러오셔서 이야기를 했다.

최근 정신적으로 지쳐있었는데 너무 힘이 났다😭😭

오늘 배운 것

• 구글 지도 API를 이용해서 두 위치 간 거리, 이동시간 데이터를 추가했다.

오늘은 아침부터 3시반까지 쭉 DB설계를 했다.

기능에 대한 인식이 팀원끼리 달라서 서로 이해를 하는데 시간이 많이 걸렸다.

그래도 이제서라도 방향이 맞춰진 것 같아 다행이다.

뜨거운 토론을 계속 해서 그런건지 다른 이유인건지는 모르겠지만 DB설계가 끝난 뒤 오후 내내 너무 피곤하고, 의욕도 떨어졌다.

시간을 허비했다.

오늘은 학습방법을 다시 돌아보는 시간을 가졌다.

시간을 조금 더 유용하게 쓰고 싶어서 생각을 많이 했다.

오늘 배운 것

• 배열에서 중복없이 n개(아래의 예시는 4개)까지 랜덤으로 뽑는 코드

  const myArray = [1,2,3,4,5,6,7,8,9,0];
  const newResult = [];
  // 10개까지는 필요없어서 저 중에 4개만 뽑고싶어용
  
  while (newResult.length < 4) {
  // 결과 배열에 4개 들어올 때 까지 반복
    const poppedElement = myArray.splice(
      Math.floor(Math.random() * myArray.length), 
      1)[0];
    newResult.push(poppedCourse);
  }

• ubuntu에서 pm2로 스크립트를 실행할 때 아래와 같이 했다.

  pm2 start npm --name "{app_name}" -- run {script_name}
  pm2 start npm  -- run start:dev

• 상수는 constants 파일을 하나 만들어서 집어넣으면 된다. @IsIn()과 상수의 조합..☺

• API의 건수가 제한되어 있을 때에는 신중하게 쓰자. 괜히 절반 날려먹었다.

오늘은 집중력이 좋지 않았다.

오전에는 몽고DB의 데이터를 Postgre로 옮기는 작업을 했다.

괜찮게 했다.

근데 오후에는 금방 끝낼 일을 하루종일 붙들고 있었다.

손을 대니 15분 정도만에 끝났다.

집중 좀 하자. 뒤쳐지는 중이라 생각하고 하루하루를 소중하게 써야한다.

내일은 프론트와 이야기해서 개선해야 할 부분, User모듈이 완성되었으니 Trip의 함수들을 User랑도 연결시키도록 고칠 것이다.

오늘 배운 것

• TypeORM의 함수를 이용해서 DB를 여러번 참조하지 않도록 개선했다. where().andWhere()를 사용했다.

• Nest.js에서는 모듈끼리 서로 서로 import할 수 없다. Circular Dependency라고 하는데, 웬만하면 이런 상황이 없는게 베스트이고, 어쩔 수 없을 때는 forwardRef라는 함수를 사용하면 된다. 공식문서가 아주 잘 설명해준다. https://docs.nestjs.com/fundamentals/circular-dependency

드디어 기존에 있던 서버를 Nest.js로 전환하는 작업을 시작했다.

오전에는 계획과 서버 틀을 짜고, 오후부터 작업에 들어갔다.

오전에는 개략적인 DB구분만 해놨었기에, DB설계를 좀 해보려 했는데, 관계설정이 너무 어려웠다.

1:1, 1:N 관계를 만들어 주려는데, 어디에다가 외래 키를 넣어줘야 하는지도 모르겠어서 여러 문서를 찾아보다 결국 생활코딩님의 영상을 보고 조금은 이해가 되었다.

그런데도 실전에서 쓰려니 막막했다.

예를 들면, Course라는 테이블이 있고, 거기에 속하는 Location들이 있다고 치자. 1대N에서는 N에다가 외래 키를 준다는데, 이 부분이 이해가 안간다. Course에 Location이 Join하도록 하고싶은데, N에 외래 키가 있으면 Location에 Course가 Join하지 않는가. RDBMS의 사고방식을 따라가지 못하고 있다.

오늘 배운 것

• 1:1 관계에서는 다른 쪽에 의존하고 있는 테이블에 외래 키를 준다.

• 1:N 관계에서는 N에 외래 키를 준다.

• N:M 관계에서는 둘을 이어주는 테이블을 하나 만든다.(통상적으로는)

이번 주에는 Nest.js로 REST API를 구현하는 방법을 공부하는 것에 초점을 맞췄다.

Express를 쓸 때에, 항상 고민되었던 부분이 아키텍처였다.

Express Project Best Practice같은 키워드로 검색을 해보면 계층 구조를 많이 쓰던데, 결국 공식적으로 정해져있는 것은 아닌지라 개개인이 쓰는 구조가 전부 다르다.

각각이 무슨 역할을 하는지 적어놓은 블로그는 많은데 결국 구체적으로 어느정도 범위까지 하는지 감이 오지 않았다.

그런데 Nest.js를 사용하면 Nest.js가 구조를 딱 정해주기 때문에 구조를 고민할 필요가 없다.

그런 부분에서 나는 Nest.js가 너무 마음에 든다.

누군가에겐 구조가 정해져있는게 단점일 수 있지만, 나에게는 큰 장점으로 작용한다.

공식문서의 설명들도 매우 친절하고, 예시로 사용하는 코드들이 비슷해서 이해가 쉽다.

또, 초기설정을 전부 세팅해주는 것도 너무 편하다.

데코레이터 기능도 매우 직관적이다.

나는 Nest.js와 사랑에 빠졌다.

앞으로도 Nest.js와 많은 프로젝트를 함께 하고 싶다.

실제로 프로젝트를 하다보면 단점이 있을 수도 있겠지만 현재는 아직 배우는 단계이기에 장점밖에 안보인다.

굳이 하나를 꼽자면 아직까지 쓰는 사람이 많이 없어서 커뮤니티가 한정적이라는 점이 있겠다.

Nest.js의 장점 정리

• 타입스크립트와 연계가 아주 잘된다. 매우 안정적이다.

• 구조가 정해져있다.

• 프로젝트 세팅을 다 해준다.

• 직관적인 데코레이터 기능

다음주부터는 본격적으로 원래 있던 서버를 Nest.js로 재구성한다.

DB설계에 시간을 오래 투자해야 할 듯 하다.

오늘은 일요일이어서 푹 쉬었다.

오늘도 열심히 Nest.js의 진도를 나갔다.

• Guard를 만들었다.

• express에서는 미들웨어로 전부 처리하던 기능을 Nest에서는 세분화 시킨 느낌이다.

• @UseGuard로 라우터에 사용가능하다. 순서는 미들웨어 다음으로 실행된다.

• 커스텀 데코레이터를 만들었다. 귀엽다.

• 선택적으로 가져오되, 전부 옵션으로 가져오고 싶을때에는 PartialType(OmitType()) 이렇게 중첩시킬 수 있다.

• typeORM의 update함수로는 @BeforeUpdate 데코레이터가 작동하지 않는다. save()를 써야 작동한다.

• Object.assign()으로 여러 개의 오브젝트를 쉽게 병합할 수 있다

• TypeORM에서 테이블 간에 관계를 맺어줄 때도 데코레이터로 맺어줄 수 있다.

• uuid라는 데이터 형식?이 있는데 랜덤한 값을 잘 뽑아준다.

• 비지니스 로직은 서비스에 몰아넣고, 컨트롤러는 input 값을 전달하고 서비스의 함수를 반환하는 역할만 수행하도록!!

• MailGun으로 이메일에 변수 담아서 보내는 것까지 성공!!😊

오늘도 Nest.js를 마음껏 공부했다.

• 패스워드 암호화 함수를 Entity에 내장시켰다.
• 로그인 기능을 만들면서 JWT 모듈을 만들었다. : Dynamic Module 만드는거 재미있다
• Dynamic Module을 만드는 과정에서 모르는 부분이 있었는데, 애초에 Nest와 DI에 대한 이해부족이라 판단해, 공식docs의 몇페이지를 정독했다. 드디어 이해가 되었다. 너무 기뻤다.
• 모듈의 providers : Nest 인젝터에 의해 인스턴스화되고 적어도 이 모듈에서 공유될 수 있는 제공자
• Dynamic Module을 만들 때에는 providers로 옵션 등을 서비스에 전달한다.
• 전달되는 값이 클래스가 아닐 때는 @Inject로 주입해줘야한다
• 타입스크립트에서 object를 타입으로 쓰는 것을 권장하지 않는다고 한다.
• Nest 첫 미들웨어도 만들었다
• 유효성 검사 미들웨어인데 express랑 크게 다르지 않다
• 대신 라우터에 붙여주는 방법이 많이 다름

내일도 파이팅!

오늘도 하루종일 Nest.js 공부만 했다.

너무 재미있다.

오늘 배운 것

• TypeORM으로 postgre랑 연결

• ConfigModule로 환경설정

• Entity 수정할 때 마다 DTO도 수정해주는게 번거로웠는데, Mapped Types로 해결

• 커스텀 데코레이터 한번 만들어보면 감이 올 것 같은데 그 한번이 어렵다

• 에러를 띄워주는 방법이 다양해서 고민된다. 나는 그냥 status code까지 넘겨주는게 속 편하다

오늘은 오전에 API를 수정하고 오후에 Nest를 공부했다.

몇 번을 생각해봐도 Nest는 너무 편하다.

미니 프로젝트 때 부터 express만 쓸 때 프로젝트의 구조를 어떻게 해야 효율적일지 계속 고민해왔다.

express의 장점이자 단점이라 할 수 있지만 정해주는 것이 아무것도 없기 때문에 효율적인 구조도 스스로 정해야 하고, 협업을 할 때 일일히 구조를 협의해서 결정해야 한다는 점이 불편하게 느껴졌다.

Nest는 구조가 딱 정해져있고 초기설정도 알아서 다 해주기에, 팀원들이 쓸 줄 안다면 최고의 선택지라 생각한다.

Nest를 공부하면서 중간중간에 이걸 왜 써야하는지, 어떤 장점이 있고 어떤 단점이 있는지 계속 찾도록 신경쓰고있다.

오늘 튜터님과의 면담을 통해 DB캐싱, Redis를 알아보기로 했다.

이번 프로젝트에는 DB에 들어갈 데이터의 양이 꽤 많기 때문에, DB의 성능을 끌어올리는 것에 챌린지해보면 좋을 것 같다는 피드백을 받았다.

키워드 : 쿼리 최적화, Redis

오늘 배운 것

• Nest님은 바라는 것을 요청해야 줍니다. 그래서 @Query, @Body, @Param 등의 데코레이터에 익숙해져야합니다.

• validation pipe라는것으로 DTO를 검증합니다.

• DTO란 데이터를 이런 식으로 보내줬으면 한다고 정의해놓은 틀입니다. Entity랑 차이가 뭘까요..

• PartialType으로 DTO를 쉽게 복사해 올 수 있습니다.

현재 진행 중인 프로젝트에서는 최신 문법을 쓰는 중이다.

어제 오늘 그동안 써오던 require를 떼고, import에 익숙해지려고 노력중이다.

import는 require때랑 똑같은 방법으로 써도 크게 다른 점을 못 느끼겠는데, export가 조금 헷갈린다.

module.exports를 쓸 때는 여러가지 함수들을 object로 묶어서 보내주고 바로 바로 꺼내서 쓸 수 있었는데, 똑같은 방법으로 코드를 짜서 import해서 쓰려고 하니 object 자체가 들어가버렸다.

조금 더 공부가 필요하다.

또, 커밋메시지도 형식을 맞춰서 작성 중이다. 확실히 보기 편하다.

오늘은 소셜 로그인을 구현했는데, 너무 재미있었다.

오전에 다른 서버분과 각자 카카오 네이버로 갈라져서 구현하기로 했는데 혼자 찾다보니 이해가 안됐다.

결국 오후에 팀원분이 어떻게 구현하신지 설명을 듣고, 스스로 구현해보니 이해가 되었다.

재미있었다.

이렇게 편한 API를 생각해낸 기업들이 대단하다고 느꼈다.

소셜로그인 기능을 끝내고, 팀원들과 미팅을 했다.

회원가입과 로그인 기능에 수정이 필요했기에, 서버팀 내에서 로직을 다시 한번 정리하고 역할을 분담해서 작업을 했다.

어제까지는 바로 코드로 넘어가기만 해서 서버 팀 내에서도 정리가 안되는 느낌이었다.

그래서 문서로 기능의 흐름을 확실히 정리하고나서 코드를 짜도록 신경썼다.

오늘 배운 것

• nest.js 구조가 짜여져 있어서 너무너무 편하다. 맨땅에 헤딩하던 시절(express를 써보지도 않고 nest.js 강의를 들었을 적)에는 몰랐다. 다만 타입스크립트도 확실히 공부해야 할 것 같다.

• 소셜 로그인 구현방법

새로운 주차가 밝았다.

오늘은 낮까지 기획과 DB설계를 하고, 작업에 돌입했다.

먼저 로그인과 회원가입 기능이 결국 필요하다고 판단되어, 기능을 넣기로 하고, 관련 기능을 구현했다.

백엔드 팀 내에서의 여러번의 의논 끝에 1주차에는 현재의 트래픽으로 구현 가능한 방식으로 만들기로 했다.

1차 배포한 것을 트래픽 심의에 올리기로 했다.

제발 통과되면 좋겠다.

그리고 오늘 발견한 한국관광공사에서 새롭게 개방한 API가 재미있어 보인다.

관광지의 혼잡도 예측 API인데 이걸로 재미있는 기능을 넣을 수 있을 듯 하다.

빠르게 API만들고 새로운 기술 적용해보고싶다!! 트래픽 늘어나면 새로운 추천 알고리즘도 짜보고싶다!!!

내일도 파이팅!!

오늘은 선데이지만 팀의 기획이 덜 가다듬어진 상태여서, 오후에 모여서 회의하고 Tour API의 사용성을 검증하기 위해 데이터를 가져오는 테스트를 진행했다.

좋은 데이터가 많다고 판단되었다.

그런데 필요한 데이터가 여기저기 분산되어 있어서 적은 요청으로 최대한의 데이터를 가져오도록 코드를 짜는 것이 어려웠다.

내일부터는 본격적으로 작업에 들어갈 수 있을 듯 하다.

저녁엔 영화보면서 쉬었다.

주요 이벤트

• 클론코딩 프로젝트가 끝나고, 실전 프로젝트가 시작되었다.

• 힘겹게 팀 빌딩이 되었다. 만족.

<정육각> 홈페이지 클론코딩 프로젝트가 끝났다.

너무 재미있었다.

프론트분들도 밤 늦게까지 열심히 해주셔서 덩달아 열심히 하게 된 프로젝트였다.

물론 클론코딩이라 디자인을 가져와서 그런 것인 부분도 있겠지만, 이때까지 만들었던 프로젝트 중 심미적으로 가장 훌륭한 결과가 나왔다.

팀장님에게 Git의 브랜치를 나눠서 작업하는 방법도 배웠다.

얻어가는게 많다.

중간에 MySQL로 바꿔보려고 공부를 해보고 시도를 해보는 기간을 가져보았지만, 실패하였다.

너무 만만하게 보고 덤빈 것 같다.

그래도 관계형DB가 어떤 흐름으로 움직이는지 조금은 알게되었으니 개꿀띠.

실전 프로젝트 돌입

팀 빌딩에 시간이 조금 걸렸지만, 사용해보고 싶던 기술을 채용한 프로젝트를 할 수 있게 되었다.

기쁘다😆

여행 관련 프로젝트를 하기로 했다.

한국관광공사의 API에 크게 의존하기 때문에 API를 분석해서 재미있게 가공하는 것이 임무이다.

이번 주는 기획으로 끝이 난다.

다음주도 파이팅!