JUST CODE 2차 프로젝트 회고

shorry·2022년 5월 16일

Review, 회고

목록 보기

4/7

부제)
회고록 써야하는데 라고만 하다가
이제서야 올리게 되는 뒤늦은 2차 프로젝트 회고🥲

📌프로젝트 소개

클론코딩 프로젝트 : 개발에만 집중할 수 있도록 기존 웹의 기획과 디자인을 참고하여 하나의 사이트를 완성해보는 프로젝트

클론 사이트 : 다방

프로젝트 기간 : 22.04.18 ~ 22.04.29 (2주)

프로젝트 참가 인원 : 5명 (프론트 3명 , 백엔드 2명)

📌사용한 기술

🌞Front-End

React, Styled-Components

☀️Back-End

Node.js, JWT, Express, prisma, Bcrypt, MySQL

🌝Common

Git, Github, Slack, RESTful API

📌맡은 역할

☀️Back-End

회원가입 API
✔️ 부동산 중개인, 세입자가 회원가입이 가능한 API 구현.

부동산 매물 필터 API
✔️ 부동산 매물을 보여주는 지도에서 매물의 거래 타입에 따라 필터링하여 매물을 보여주는 기능 구현.

좋아요(찜한 방) API
✔️ 클라이언트가 ( 부동상 중개인은 불가능 ) 매물에 하트 버튼을 누르면, 해당 클라이언트의 id와 클릭한 부동산 매물의 id를 테이블에 저장하고, 이미 데이터가 존재한다면 그 데이터를 삭제하여 좋아요 on/off 를 시켜주는 기능 구현.

✔️ 로그인한 클라이언트가 좋아요를 이미 해놓은 데이터를 불러와서 매물의 좋아요버튼이 on이 되도록 보여주고, 좋아요 한 방(찜한 방) 탭에 들어갔을때 좋아요한 해당 매물들을 보여주는 기능 구현.

최근 본 방 API
✔️ 클라이언트가 클릭 한 방의 id들을 프론트에서 로컬스토리지에 저장한 후, 최근 본 방 탭에 들어가면 id들의 배열을 백으로 보내주고 해당 id들의 매물 데이터들만 id배열의 순서에 맞게 보내주는 기능 구현.

에러처리 미들웨어
✔️ 레이어드 패턴으로 구성된 API에서 발생하는 모든 에러를 next()로 넘겨받은 후, 에러를 핸들링하고 처리하는 하나의 미들웨어에서 모든 에러를 처리할 수 있도록 기능 구현.

(추가구현) 사진 업로드 API (multer 라이브러리)
✔️ multer 라이브러리를 이용해, 이미지 파일만을 (확장자, 갯수, 용량등의 제한을 적용) 전송받고, 전송 받은 이미지 파일을 백엔드의 특정 디렉토리 폴더에 저장하고 해당 이미지의 url을 데이터베이스에 저장한다.

✔️ multer를 이용해 저장한 이미지를 express.static() 미들웨어를 사용하여 이미지 파일 이름의 url을 통해 접근하여 사용할 수 있도록 기능 구현.

📌프로젝트 회고

왜 이번 프로젝트에서 백엔드를?

처음 부트캠프를 시작했을 때에는 프론트에 대해서만 알고 있었고, 관심도 프론트에만 있었다.

백엔드를 배우면서 흥미가 점점 생기기 시작했지만, 프론트에 비해 상대적으로 백엔드를 많이 경험해보지 못해서 백엔드에 대한 아쉬움과 미련이 남아 있었다.

그래서 조금 더 제대로 백에 집중해 경험해보고, 그 이후에 프론트가 더 맞는지 백이 더 맞는지를 제대로 고민해보고 결정해야 아쉬움과 미련이 덜 할 것이라고 판단했다.

( 프론트와 백, 두 분야 모두 충분히 매력적이여서 내 성향에 더 맞는 쪽을 택하기로 했고, 프론트엔드 개발자로서 커리어를 쌓아가보기로 결정했다. )

어떻게 연결할 것인가.

(개인적인 욕심은 뒤로.....)

조금이라도 더 많은 API를 만들어 보고 프론트와 연결도 해보면서 이번 2차 프로젝트에서 백엔드를 맡는동안에 많은 경험을 해보고 싶었다.

multer 라이브러리를 활용한 정적인 파일 업로드, CRUD, 소셜 로그인 등의 구현해보고 싶은 다양한 API들과 기능들이 있었다.

그러나 이번 2차 프로젝트를 진행하면서, 어렵지만 가장 중요하다고 생각했던 것은 프론트엔드 팀원분들의 코드를 파악하며 백엔드와 문제없이 잘 연결하는것 그리고 백엔드의 진행상황 뿐만 아니라 프론트엔드의 진행상황을 늘 최신의 상태로 업데이트 하는 것 이였다.

그렇기에 단순 개인적인 욕심으로 백엔드에서 더 많은 코드를 짜고 더 많은 기능을 구현하려고 하는 것은 큰 의미가 없다고 판단했다.

프론트와 백에서 기능을 구현하고 코드를 짜면서 계속해서 소통하며 어떠한 형식으로 데이터를 주고받을지 의논하고 서로의 진행상황을 꾸준히 업데이트 한다면, 코드를 완성 하고 나서 연결을 할때 들어가는 추가적인 시간을 현저히 줄일 수 있을 것이고,

그렇게된다면 오히려 그 이후에 그 줄어든 시간을 활용하여 개인적인 욕심이였던 기능들도 구현해 볼 수 있을 것이다.

📌기억에 남는 코드

부동산 매물 필터 API

const getfilteredEstates = async (user, arrTradeTypes, headers, arrLatLng) => {
  const offset = headers.offset ? headers.offset * 4 : "";
  const limit = headers.offset ? 4 : "";
  const west = arrLatLng[0] ? arrLatLng[0] : 0;
  const east = arrLatLng[1] ? arrLatLng[1] : 999;
  const south = arrLatLng[2] ? arrLatLng[2] : 0;
  const north = arrLatLng[3] ? arrLatLng[3] : 99;

  return await prisma.$queryRaw`
    SELECT
      re.id,
      re.address_main,
      re.building_name,
      re.address_ho,
      re.latitude AS lat,
      re.longitude AS lng,
      re.supply_size,
      re.exclusive_size,
      re.building_floor,
      re.current_floor,
      re.description_title,
      re.price_main,
      re.price_deposit,
      re.price_monthly,
      re.room_image AS image_url,
      c.type AS category_type,
      JSON_ARRAYAGG(t.type) AS trade_type
      ${
        user
          ? Prisma.sql`
        , ( SELECT l.real_estate_id 
        FROM users_real_estates_likes AS l
        WHERE l.user_id = ${user} AND re.id = l.real_estate_id ) AS is_like
        `
          : Prisma.empty
      }
    FROM real_estates AS re
    JOIN categories AS c ON re.category_id = c.id
    JOIN trades_real_estates AS tre ON tre.real_estate_id = re.id
    JOIN trades AS t ON t.id = tre.trade_id
    WHERE
      (re.latitude BETWEEN ${south} AND ${north}) AND
      (re.longitude BETWEEN ${west} AND ${east})
      ${
        arrTradeTypes[0]
          ? Prisma.sql`AND (t.type IN (${Prisma.join(arrTradeTypes)}))`
          : Prisma.empty
      }
    GROUP BY re.id
    ${limit ? Prisma.sql`LIMIT ${limit} OFFSET ${offset}` : Prisma.empty}
    
  `;
};

prisma ORM 과 함께 SQL query문을 사용하여, 부동산 매물들 중에서, 값을 받아온 위도와 경도 사이에 있는 데이터들을 추리고 또한, 그 중에서도 user의 로그인 여부에 따라 유저가 좋아요 한 매물의 데이터를 보내줄지 말지를 결정하며, 거래 타입 (매매인지 월세인지 혹은 둘 다 인지)를 필터링으로 체크한것에 따라, 그에 해당하는 값들만을 전달해주는 쿼리문 이다.

기억에 남는 이유로는 Prisma.join 을 사용하기 까지의 과정에서 순수하게 쿼리문만으로 코드를 구현하고 싶었으나, 월세,전세 형식으로 데이터를 보내주면 월세 와 전세가 각각의 string 으로 전달이 되는 것이 아니라 월세,전세 라는 하나의 string으로 전달이 되는 문제가 발생하여 쿼리문을 작성하는데 어려움을 겪었다.

이를 해결해 준 것이 prisma ORM 의 문법이였고, 쿼리문만을 사용할때 생기는 문제나 어려움을 prisma ORM 을 이용하여 쉽게 해결할 수 있었다.

아무런 기초 지식없이 불편함도 느끼지 못한채 무턱대고 라이브러리를 사용하고 거기에 익숙해지는 것은 내가 발전을 할 수 있는 가능성을 막는 요인이라고 생각한다.

하지만 이번기회에 prisma ORM 을 사용함으로써, 지속적으로 겪고있는 문제나 어려움을 해결하고 추후에 코드를 구현하는 시간을 단축하고 좀 더 가독성이 있는 코드를 구현하는 수단으로서 라이브러리들을 사용하는 것에 대해서 직접 경험해볼 수 있는 좋은 기회였다.