TIL : 파이널 프로젝트 회고1 : 담당 작업 정리

https://youtu.be/FRmkiWnzpkE

NestJS, TypeORM, EJS 개발 환경이다.

디자이너나 프론트엔드 담당 없이, 5명의 백엔드 팀원끼리 만든 프로젝트이다보니, 시각적인 면은 좀 아쉬운 게 많지만, 그래도 DB를 다루는 방식에 대해 많이 공부할 수 있어서 의미가 컸다. 

 

서비스 기획 사유

우리 팀의 서비스는 스파르타코딩클럽의 부트캠프 수료생을 대상으로한 커뮤니티이다. 주요 기능은 모임 매칭과 행사 알림 서비스이다. 예를 들어 개발자 면접 스터디, 포트폴리오 제작, 모여서 각자 코딩 등을 하고 싶을 때 우리 서비스에서 뜻이 맞는 사람을 찾아 팀원을 매칭할 수 있도록 돕는 것이다.  

 

담당 기능 및 작업 

나는 이 프로젝트에서 주로 조회 기능을 다루게 되었다. 주요 기능(회원가입 및 로그인/유저페이지/행사알림 게시판/모임 구성 게시판)을 담당하진 않았다. 약간 깍두기랄까? 나는 웹소켓을 활용한 실시간 채팅 기능을 이번 프로젝트에서 도입하면서 담당하고 싶었는데, 우리 서비스에 꼭 필요한가? 자문을 해보면 그렇지 않았기에, 아쉬운 마음에 다른 팀원들이 기능 담당을 먼저 선택할 때까지 기다렸다. 그러다보니 맨 처음에 지난 번에 구현했던 검색기능을 담당하기로 했다. 그러고 역할 분배가 끝이 났다.

 

처음엔 클라이언트 사이드 초기 구성과 검색 기능만 담당했는데, 지난 프로젝트에서 Sequelize로 검색기능을 구현해봤던터라, TypeORM 를 사용했음에도 검색 기능은 금방 구현을 완료했다. 다른 팀원들이 작업 진도를 빼는데도 시간이 걸리다보니, 약방의 감초 혹은 소금 같은 존재처럼 눈에 띄지 않지만 전체 작업에는 기본적으로 필요한 일로 생각되는 작업을 찾아서 하게 됐다. 

 

@ 메인 : EJS 템플릿 엔진 및 라이브러리 셋팅

작업 배경

- 지난 프로젝트에서 내가 발견했던 express-ejs-layouts 라이브러리의 팀원들에게 이점을 설명하고 도입을 추진했다. 이 라이브러리를 사용할 때와 사용하지 않을 때 페이지 렌더링을 작업하는데 필요한 유지보수에 대한 노력 차이가 크다.

- 설득은 어렵지 않았다. 직전 프로젝트에서 같이 했던 팀원들부터 이 라이브러리에 대한 반응이 뜨거웠기 때문이다. 직전 팀 동료들 역시 유지보수의 편리성에 대해 효과를 체감했다고 피드백을 주었을 뿐만 아니라, 이들 다수가 파이널 프로젝트를 위한 새로 구성된 팀에 돌아간 뒤 EJS를 사용하는 경우 이 라이브러리를 도입을 시키기도 하였다. 그래서 사용 효과에 대해서 쉽게 이야기할 수 있었다.  

- 프로젝트 초기, 나는 다른 팀원들이 담당 기능 API에 집중할 때, 각자가 만든 API가 화면에서 보일 수 있도록 먼저 셋팅을 하는데 집중했다. API를 만들 때 테스트 하기 위하여 PostMan이나, Thunder Client 같은 것을 활용할 수 있겠지만, 어차피 화면단과 API를 연결을 해야하는 이유가 있을 뿐더러, 화면 단에서 연결한 뒤 테스트하는 게 더 직관적이기 때문에 나는 빨리 템플릿 엔진 셋팅하는 것을 중요하게 여겼다.

- 또한 미니프로젝트 여러 번 경험하다보니, 백엔드에만 치중한 팀들은 결국 일주일간의 프로젝트 기간내에 자신들이 만든 API를 화면에서 보여주지 못해 발표도 못하는 불상사가 있기도 해서, 겸사겸사 빨리 셋팅을 해놓았다. 팀원들 모두가 백엔드 구성에 집중하는 사이에 소홀히하는 것을 찾아서 하게 된 셈이다.

 

문제상황 및 문제설정, 해법, 알게된점  -> 자세히보기 https://veams.tistory.com/71

- 라이브러리 적용을 위해 미들웨어를 셋팅을 시도했는데, express에서 사용하던 app.use 방식이 nestjs에서 사용할 때는 잘 적용이 되지 않았다.

- 대신 전역 미들웨어를 사용하는 법을 알게 됐고, 모듈을 불러오는 과정에서 express에서 주로 사용하던 const ... = require(' ... ' ) 의 선언 방식을 넘어서, import {...} = from ' ' 과  import * as .. = require()의 차이에 대해서도 알게 되었다.

- EJS 사용이 다른 팀원들보다 좀 익숙해져서, 이와 관련해서 백엔드와 EJS를 연결해서 활용하는 문제들을 좀 많이 해결하게 된 것 같다.

- ex1) 인터셉터 활용하여, 기존에 ajax로 작성된 코드에서 로그인 유무에 따른 버튼 변경 오류 해결, ex2) AuthGuard로 적영된 미들웨어를 Optional로 적용하여 로그인한 유저만 수정 및 삭제 버튼 공개

 

https://veams.tistory.com/71

[TIL] : Nestjs 에서 express-ejs-layouts 사용하기 require() vs import()

https://veams.tistory.com/76

[TIL] nestjs, 특정 페이지(URL)만 미들웨어 예외 처리

https://veams.tistory.com/80

TIL : NestJS 인터셉터 사용으로 코드 리팩토링 (유저 로그인 정보에 따른 버튼 처리)

 

 

@ 메인 : 인기글

- 만약, 유저가 어떤 웹사이트에 방문했을 때 단순 게시글만 나열된 이 서비스를 본다면 어떨까? 나는 당혹감을 느낄 것 같다. 왜냐하면 자신이 어떤 게시글부터 보아야 할지, 선택지가 너무나 많기 때문이다. 많은 선택지가 주는 역설적인 상황이 발생한다.

- 그렇기에 인기글(현재 인기있는 게시글 안내) 기능을 만들어서 이전에 이곳에 방문했던 사람들은 가장 어떤 글에 관심이 있을까?에 대해서 가이드를 주려고 했다.

- 우리 팀은 초기 ERD 설계시에 각 게시판(모임 게시판 / 행사게시판)의 테이블을 다르게 구성했다.

- 즉, 엔티티가 다르기에 나는 두 엔티티로 생성된 게시글의 데이터를 합친 배열을 구성했고, 이를 조회수 기준으로 재정렬하여 보여준다.

- 처음에 이를 구현하는데 애를 먹느라... '어차피 게시글 타입 그렇게 차이가 나지도 않는데, 그냥 게시글 엔티티를 하나로 구성했으면 어땠을까' 생각이 마구 들었던 작업이다.

- 이벤트(행사알림) 게시판, 클럽(모임구성) 게시판 사이에는 공통적인 컬럼이 대부분인데, 초기 설계한대로 엔티티를 둘로 나눠놓고 작업을 하다보니, 이런 인기글 계산하는 작업의 난도가 올랐다는 생각은 든다. 

@ 메인 : 활동왕 선정 및 포인트 계산

- 작업 후반부에 '이 커뮤니티에서 유저가 더 활발히 활동하게 하려면 어떻게 할까?' 라는 의문에서 작업을 시작했다. 

- 사실 초기 설계에서 활동 순위 및 포인트 측정 기능은 계획하지 않았다. 

- 그렇기에 유저 엔티티에 포인트 컬럼은 당연히 존재하지 않은 상태였다. 컬럼이 존재했으면 조회수 오르는 듯이 게시글, 댓글 작성할 때마다 포인트가 오르는 식으로 적용했으면 구현하기 쉬웠을 것 같은데, 팀원들이 대체로 컬럼이 추가되는 걸 반기지 않는 상황이었다. 각자가 기존에 구현한 코드를 변동하게 될 수 있다는 두려움이었다.

- 더 중요한 것은, 막상 컬럼을 추가한다고 하더라도 기존에 작성했던 게시글 댓글등에 대한 계산을 어떻게 할 것인가 의문이 들었다.

- 그래서 user 리포지토리를 중심으로 각 게시글, 댓글, 받은 좋아요, 조회수 등을 DB에서 Join 처리하고, deletedAt=null 인 것을 필터링하고 포인트를 구성해봤다.

 

활동량 측정 : 각 게시판 게시글 작성 갯수*1점 + 댓글 작성 갯수*1점 + 댓글 좋아요 갯수*1점+ 작성 게시글 조회수*0.1점

 

CSS 공부도 꽤 됐다. 활동왕, 인기글 표는 CSS의 template-grid를 학습해서 적용하게 된 방법이다. 총 4개 grid를 만들어서 활동왕, 인기글의 width의 넓비는 고정값을 주고, 맨 가장자리 grid는 auto 값을 주어서 창 크기에 따라 조절이 된다. 

 

filter() : 배열에서 주어진 함수를 만족하는 요소들을 모아 반환.

map() : 배열의 요소를 돌면서 요소에 어떤 함수 처리를 한 결과를 모아 새로운 배열을 반환. 배열 요소들에 일괄적인 함수를 적용할 때 사용.

reduce() : 배열의 요소를 돌면서 함수를 실행하고 하나의 결과값을 반환. 요소에 대해 함수를 실행한 결과값이 누적됨.

참고 : https://brunch.co.kr/@swimjiy/15

 

후기

1.조회 API 접근시 조회수를 카운트하는 기능을 구현해보고 나니까, 그 다음으로 유저 활동 순위를 적용하는 것도 해볼만해보였다. 전 프로젝트까지는 for문을 사용하다가, 이번 프로젝트를 하면서 forEach를 활용하기 시작했고, 프로젝트 후반부에는 filter(), reduce(), map() 을 활용하는 법을 조금 익히게 됐다.

 

2. 아쉬운 것은 조회수 카운트 방식이다. 단순하게 게시글 상세 API 접근시 +1씩 오르는 것으로 구현하였는데, 배포하고, 사용자 피드백을 받아보니, 조회수가 단순하게 오르는 것에 대한 피드백이 있었다. 큰 고려를 하지 못했던 것인데, 제한 시간 내에 동일 IP에서 여러번 접근시 중복으로 조회수가 오르지 않도록 고도화할 수도 있다는 걸 알았다.

 

@ 검색 키워드 조회 - 검색 (유저 / 게시글 제목 / 타이틀)

- 초기에 단순히 딱 일치하는 키워드만 조회되는 상태이다. 이보다 고도화하고 싶은 욕심이 컸는데, 우리 팀이 작업 속도가 많이 늦은 것 같아서, 다른 팀원 기능을 돕다보니 초기에 기본만 구현해놓게 되었다.

- 유저피드백에도 검색 타입에 제목+내용 만 있는 게 불만족스럽다는 의견이 있었다. 그래서 검색 타입을 추가하기로 했다. 프로젝트 막바지에 검색 타입(제목+내용 / 제목) 옵션을 적용하는 방법을 빠르게 찾아보았다. 

- DB에서 제목만 검색하는 것은 어렵지 않다. 검색 키워드에 대해 Like 연산자를 이용하여 제목 OR 내용으로 검색하던 것에서 제목만 검색하면 되기 때문이다.

 

문제상황

- 문제는 검색 타입을 추가하고 페이지를 이동하니, 선택한 검색 타입이 유지되지 않는 것이 문제였다. 예를 들어 '제목'타입을 선택해서 검색을 하고, 검색 목록에서 1페이지-> 2페이지로 이동하면 내가 선택한 '제목'타입이 '제목+내용'타입으로 바뀌어있는 문제가 있었다.

 

문제 규정

- 유저가 선택한 타입을 유지 및 저장하는 방법이 필요하다.

- 검색시 유저는 자주 사용하는 검색 타입을 계속 사용한다.(가정)

- 추후, 검색했던 키워드를 저장하는 등 기능의 확장성을 고려해볼 때, 선택한 검색 타입은 지속적으로 보관할 필요성을 느낀다. 

 

해법

-  localStorage 사용. 자바스크립트에는 sessionStroage와 localStorage 라는 방식이 있는데, localStorage는 유저의 어떤 데이터를 DB에 저장하는 게 아니라, 브라우저에 저장하는 메써드이다.

- SessionStorage는 세션이 끝날 때(브라우저를 닫을 때) 데이터가 지워지는 반면, localStorage는 세션이 끝나더라도 지워지지 않는다. 

참고: https://www.daleseo.com/js-web-storage/ 

 

코드에 적용한 결과는 다음과 같다.

<script>
  // 이전에 선택한 드롭다운 옵션을 저장
  const selectedOption = localStorage.getItem('selectedOption');
  if (selectedOption) {
    document.getElementById('searchOption').value = selectedOption;
  }
  
  // 드롭다운 옵션이 변경될 때마다 localStorage에 저장
  document.getElementById('searchOption').addEventListener('change', function() {
    localStorage.setItem('selectedOption', this.value);
  });
  </script>

- 검색 서비스에서의 앞으로 챌린지 요소는 엘라스틱 서치 도입, 키워드 간 공백을 자르기, 검색 결과 볼드체 표기 자동완성, 최근 검색기록 저장 등이 될 것 같다.

@ 페이지네이션 - 페이지네이션(오프셋 방식)

- 기존에 내가 구현한 검색 조회 결과와도 연동이 되어있던 상태라서, 처음에는 검색기능+페이지네이션이 합쳐진 코드를 만들어버렸다. 나중에 검색 기능이 제외된 게시판 조회용 페이지네이션을 만들면서 함수로 구성했다.

- 페이지네이션은 게시판의 기본 기능이지만, 사실 우리 서비스의 핵심 서비스가 아니라서 기본만 해놓고, 필수 기능을 구현하는데 시간을 쏟았다. 

- 웬만큼 구현해놨을 때도, 예를 들어 더 이상 불러올 게시물이 없는데 '다음' 페이지 버튼이 한 번 더 생긴다든가 등의 오류가 났는데, 뭐가 문제인지 몰라서 마감하고 완성을 시키는데 시간이 좀 더 걸렸다.

- nestjs는 페이지네이션에 대한 라이브러리 제공하는데, 라이브러리를 사용했으면 더 쉬웠을까 싶다. 사실 CreateQueryBuilder에서 제공하는 take() skip()을 나중에 알게 되었는데, 이걸 활용했으면 더 간단하게 구현하지 않았을까 싶다.

async function paginatedResults(page, selectedData) {
  const take = 6;
  const totalDataCount = selectedData.length;
  const startIndex = (page - 1) * take;
  const endIndex = page * take;

  const slicedData = selectedData.slice(startIndex, endIndex);
  const lastPage = Math.ceil(totalDataCount / take);

  const unitSize = 3;
  const numOfUnits = Math.floor((page - 1) / unitSize);
  const unitStart = numOfUnits * unitSize + 1;
  const unitEnd = unitStart + (unitSize - 1);
  const paginatedDemand = { page, slicedData, lastPage, unitStart, unitEnd };

  return {
    ...paginatedDemand,
  };
}

@ 게시판 및 게시글 상세 - 시간 및 날짜 표기 문제

- 팀원 모두가 초기 설계에서 미쳐 생각하지 않던 기능인데, 생각해보니 필요했고, 구성하는데도 시간과 에너지가 필요했다. date-fns 라이브러리 사용. 당일 작성글은 HH:MM 표기, 하루 지나면 yyyy:mm:dd 표기. 그냥 날짜만 표기할 수 있었겠지만, 이건 좀 성의가 없어보이고, 단순했다.

- 대부분 커뮤니티의 게시글 포멧을 참고해보니, 작성일 당일 기준으로 표기가 바뀌고 있었다. 그래서 조건문을 사용하여 만들었다.

- 만들고 나서, 온 게시글, 댓글에 적용했는데, 반복 코드가 지저분했고, 유지보수할 때도 손이 너무 갔다. 일일히 코드를 바꿔야했기 때문이었다.

- 리팩토링의 필요성을 느껴 함수로 리팩토링을 했다. 라우터 만드는 것을 제외하고는 함수를 잘 쓰지도 않았는데, 이걸 해결하고나서는 코드 실력이 더 늘어난 것을 체감했다.

- 시간 데이터는 DB에 UTC 기준으로 저장되고 있었다. 그러다보니 한국보다 9시간이 느리게 표기되었다. 이에 대해 튜터님께 물어보니 반응이 달랐다. 실무에서는 유저 타겟이 누구냐에 따라서 애초에 저장을 달리한다는 분이 있었고(한국 서비스냐, 전세계 서비스냐, 한국이면 애초에 한국 기준 저장), 미국에서 현업으로 일하시는 튜터 분은 당연히 UTC 기준 UNIX timestamp로 저장한다고 한다고 하셨다. 담당 튜터님꼐는 UTC로 기준으로 저장하고 유저의 지역에 따라서 달리 보여주는 getTimeZoneOffset()을 제안을 받아서 적용했는데 막상 heroku 유럽 서버로 배포했더니 한국에서 사는 나한테도 UTC 기준으로 그대로 나오길래, 어차피 한국 사람만 사용하기에 한국기준으로 UTC에서 +9으로 더하는 것으로 코드를 바꾸었다.

const { isSameDay } = require("date-fns");
const { format } = require("date-fns-tz");

function reformPostDate(postObjDate) {
  const currentDate = new Date();
  const postDate = new Date(postObjDate.setHours(postObjDate.getHours() +9))

  if (isSameDay(postDate, currentDate)) {
    return format(postDate, "kk:mm");
  } else {
    return format(postDate, "yyyy-MM-dd");
  }
}

https://veams.tistory.com/78

TIL : 리팩토링, JS 함수 만들어서 프론트엔드 코드 줄이기.(nestJS, EJS)

@ 모임 게시글 상세 - 1. 모임 참여자 현황 조회의 문제 

문제상황

- 부트캠프 수료생 대상으로 스터디/포트폴리오/면접 스터디 등 모임을 매칭하는 게시판

- 초기, 팀원들은 그냥 모임 모집현황을 숫자로만 2명/5명 같은 형식으로 보여주자고 설계를 했다. 기능을 구현하고 유저에게 사용 피드백을 받아보니, 만족스럽지 않다는 의견이 있었다.

 

문제규정

- 나는 우리가 구현한 기능이 유저들에게 가시성과 직관성에 아쉬움을 준다고 생각했다. 내가 유저로서 사용해봐도 그렇다. 예를 들어 '모임신청 대기자 -> 참가자의 상태 변화'를 유저가 체감하기가 어렵다고 생각했다.

- 나는 유저가 우리 기능을 더 만족스럽게 사용하려면 시각화 시키는 것이 중요하다고 생각했다.

 

해법

- 그래서 유저에게 참가자, 대기자를 카드형식으로 보여주는 API를 추가 구현했다.

- 처음엔 이것도 그냥 단순 표, 테이블로 구현하려다가 이전 쇼핑몰 프로젝트에서 상품을 카드처럼 보여주던게 떠올라서, 참여자, 대기자에 대한 표기도 카드 방식으로 표현해봤다.

@ 모임 게시글 상세 - 2. 모임정원 기준의 혼란

문제상태

기존에는 '게시글 작성 API'와 '모임 신청서를 제출하는 API'가 따로되어 있었다. 이로 인해 모임을 구성하려는 게시글 작성자는 정작 모임 현황에 표기되어있지 않게 구현되었다. 현황에 표기되려면 게시글 작성자가 자기 모임에 모임 신청을 해야했다.

- 기능이 만들어지고 배포하며 유저들을 사용하게 해보니, 게시글 작성시에 모집 인원 설정에 대한 혼란이 있었다. 예를 들어 모임 인원을 5명을 모은다고 기재할 때, 게시글 작성자는 정원에 포함되는 것인가, 아닌가?에 대해 혼동이 생기는 것이다.

- 이에 유저들은 게시글 작성자마다 각자 기준을 설정하며 게시글을 작성했고, 결과적으로 각 게시글마다 통일성이 없어졌다. 

- 모임을 신청하려는 유저들은 각자 다른 기준으로 표현된 게시글들을 보며 사용에 불편함을 경험했다. 모집 인원에 대한 혼란으로 사용자 경험이 떨어지는 것이었다. 

 

문제설정

- 이 문제를 해결하기 위한 첫 번째 선택지로는 공지사항 등을 작성하여 현재 기능을 유지하고 유저에게 사용법을 알려주며 학습시키는 방법이 있다.

- 두 번째 옵션은 유저가 크게 학습할 필요 없이, 게시글 작성자는 자동으로 모임 구성원으로 포함시키는 것이다. 게시글을 작성되면 게시글 작성자가 모임 인원으로 표기가 되기에, 작성자는 글 작성 후 모임 인원으로 속한다는 것을 금방 인지할 수 있었다. 나는 두 번째 방법이 개발자가 할 일이라고 생각했다.

 

해법 : 게시글 작성자는 게시글을 작성하자마자 바로 자신의 모임에 참여하도록 API를 재구성했다. 

- 작성자가 게시글을 작성하자마자, 어떻게 멤버로 참여하게 만드냐라는 의문이 생긴다. 나는 그 방법은 두 개 함수 간의 관계를 Promise기반으로 적용해서 구현하면 된다고 생각했다. 다시 말해, 게시글 작성 함수+모임 신청 함수를 순차적으로 적용하면 된다. 게시글 작성 함수 실행이 완료될 때, 모임 신청함수를 위치시키는 것이다. 즉, 게시글 작성 함수 내에 모임 신청 함수를 포함시키면 된다. 물론 모임 신청과 함께, 참여 수락도 동시에 설정한다.

- 문제는 작성자가 방금 작성한 게시글의 번호(기본키-Id) 값을, 로직이 어떻게 알아차릴 수 있게 하느냐 말이다. 게시글 작성하면, 그때그때 달라질 수 있는 게 게시글 Id값 아닌가? 이 달라지는 값을 어떻게 알아 낼 수 있을까?라는 의문이 들었다.

- 그러다가 발견하게 된 방법이 다음과 같다. TypeORM에서 제공하는 개념 중 하나가 identifiers이다. 엔티티의 기본키(primary key) 값을 자동으로 생성하고 반환한다. 즉, 엔티티를 저장하면서 자동으로 생성된 기본키 값을 identifiers로 확인할 수 있다.

- 예를들어 게시글을 작성하면 게시글의 Id 가 자동으로 생성될텐데, TypeORM은 엔티티를 저장하면서 자동으로 해당 엔티티의 기본키 값을 생성하고, 이 값을 identifiers 배열로 반환한다.

- identifiers 배열의 첫 번째 요소에는 생성된 엔티티의 기본키 값인 Id값은 따로 설정하지 않는 이상 객체에서 0번째로 들어가니, 방금 작성된 게시글 정보의 0번째 인덱스를 찾는 식으로 Id 값을 가져와놓고, 모임신청 메써드를 실행할 때 동시에 방금 찾아온 게시글 Id 값을 매개변수로 기재해놓는 방식으로 설정했다. 

회고 및 알게 된점

- 자동참여가 없던 당시, 클럽 게시판 담당 팀원이 insert() 쿼리 매써드를 활용하여 게시글이 작성되도록 코드를 작성해놓았다. 나는 작성자 자동 참여를 위해서 기존 로직에 이어서, insert()에 identifiers[0].id 방법을 찾아 작성하였는데, 이 코드에 아쉬움이 남는다. 흔하지 않는 방식의 로직이기 때문이다. 다음에 이런 상황이 다시 온다면 다음과 같이 변경할 것이다.

    const clubpost = await this.clubRepository.create({
      userId,
      title,
      content,
      maxMembers,
      category,
    });

    const { id } = await this.clubRepository.save(clubpost); 
    await this.createApp(id, userId, '작성자 우선 참여', true);

게시글 작성시 create()와 save() 매써드를 사용하면 id 값을 찾기 쉽다. 이전 방식이 작성 게시글의 데이터를 먼저 저장(insert)이 일단 이뤄지고 그 뒤에 id를 찾는 방식이었다면, 지금 소개하는 방식은 1) 게시글을 생성(create)한 뒤, 2) 그 게시글 정보 저장(save)하며(Select 쿼리 사용하여 reload), 3) 동시에 그 게시글 정보에 대한 값 중 id를 객체구조분해 할당으로 '변수'로 선언, 4) 그 변수를 모임 참여 함수에 인수로 할당하는 것이 차이이다. TypeORM의 create()와 save()에 대해서 알았다면 로직 다시 검토하여 구성했을 텐데, 당시 그것 까지는 생각을 하지 못해서 아쉬움이 남는다. 잘 사용하지도 않는 identifiers를 사용하는 것은 코드 가독성 면에서 좋은 방식이 아니었다고 생각한다.

- 참고 : TypeORM에서의 insert() vs save() https://jhyeok.com/typeorm-save-options/

@ 모임 게시글 상세 - 3. 다음글, 이전글 표기

- 현재글의 상세 데이터를 가져오는 것은 가장 기본적인데, 다음글, 이전글 가져오려니, 어떻게 가져와야하나? 라는 질문에서 시작됐다. 결론은 조회하는 게시글 ID 보다 숫자가 적거나, 낮은 것을 찾으면 된다. TypeORM에서는 LessThan 혹은 MoreThan이라는 방식을 사용할 수 있다. createQueryBuilder를 사용하면 오른쪽과 같다.

 

 

 

 

https://github.com/miu-null/spartasix

GitHub - miu-null/spartasix: sparta community club

 

 

https://veams.tistory.com/82

TIL : 파이널 프로젝트 회고2 : 협업 경험 후기