2차 Project 회고록

📑 2차 프로젝트 소개

유튜브 영상 😎

보러가기 ⬇️

Github [BackEnd]

프로젝트 소개 🎥

관찰 사이트 : NIKE

팀 명 : Just Do It

프로젝트 목표 : Wecode에서 배운내용을 활용하여 관찰한 사이트의 기능개발 및 레이아웃 그리기

진행기간 : 2021년 1월 17일 ~ 2022년 1월 29일 ( total : 12days )

프로젝트 참여자 : 이준혁, 김영욱, 이진웅, 황희윤

- 기술스택 -

FrontEnd 기술 스택

⭕ [React]⭕ [Router]⭕ [Sass]⭕ [Restful API]⭕ [Git & GitHub]

BackEnd 기술 스택

⭕ [Node.js]⭕ [Express]⭕ [MySQL]⭕ [Bcrypt, JWT]⭕ [Prisma]⭕ [babel]⭕ [node-cron] ⭕ [Jest]⭕ [supertest]

- Page & API -

이준혁

[back]- Draw API- Detail API- Cart API- Search API- MiddleWare

김영욱

[back]- List API- Filter API- Review API- KAKAO API- Member API

이진웅

[Front]- 로그인 페이지- 리스트 페이지- 대문 페이지- 카트 페이지

황희윤

[Front]- 디테일 페이지- snkrs 디테일 페이지

🧑 회고

---

1차 프로젝트는 e-commerce사이트를 클론하였기에 2차 프로젝트는 e-commerce사이트가 아닌 다른 플랫폼을 하고 싶었지만

아쉽게도 나이키를 모티브로하는 프로젝트를 맡게되었다.

그래도 나이키만의 감성이 있으니 상관은 없다.

회고는 기억에 남는것 몇가지만 쓰도록 하겠다.

🤮 [회고-1] DB 데이터작업

우선 나이키의 특징은 많은 제품들, 그리고 그 제품들을 세분화시켜주는 필터기능, 추첨기능 이렇게 3가지이다.

나랑 영욱님은 DB 모델링이 끝나자마자 나이키의 특징을 살리기 위해 DB에 들어갈 제품들, 제품사진들을

수집하고 집어넣었는데.. 총 166개의 제품과 x4 만큼의 사진을 DB에 넣었다.

특히 각 제품별 사이즈의 수량을 집어넣는 과정이 괴랄했는데

const style_code = ['ACA', 'ACB', 'ACC', 'ACD', 'ACE'];
for (let j = 0; j < style_code.length; j++) {
  for (let k = 1; k < 4; k++) {
    for (let i = 1; i < 10; i++) {
      console.log(`("${style_code[j]}-000${k}",${i},80),`);
    }
  }
} // 정확히 생각은 안나지만 대충 이러한 형식이었던 것 같다.

도저히 수작업으론 할 수가 없다고 판단하여 알리고즘을 통해 DB에 넣었다.

몇몇 다른작업들도 수작업이 힘들다 싶을땐 알고리즘을 통해 간편하게 생성하여 DB에 넣었다.

전혀 생각치도 못한 부분에서 시간을 많이 잡아먹어서 조금 놀랬는데,

앞으로 DB 데이터작업이 많은 프로젝트라면 샘플로 몇개만 넣고

모든 API가 완성되어졌을때 데이터를 넣는것이 현명한 판단일 것 같다.

😁 [회고-2] 소통

데이터작업, prisma로 스키마 만들기 등 다양한 것들을

vsCode의 Rive Share와 Zoom, Slack을 이용하여 영욱님과 함께하니 크로스체킹을 통해 놓치는 것이 없었다.

(물론 둘다 몰랐던것을 제외하곤)

이러한 과정때문이었을까? 영욱님과 케미가 잘맞았고 소통에 대한 불편함?은 느끼지 못했다.

또한 영욱님이 책임감도 갖고 프로젝트에 임하는걸 알게되어 믿고 맡길 수 있었고

솔직히 프로젝트 기간내내 백엔드 작업은 재밌었다.

하지만 front와의 소통이 문제였다.

두명이서 UI작업을 모두 하려고 하다보니 너무 바쁜것 같았고

그 때문에 생각보다 우리와의 교류가 없었다.

‘API를 ~~~한 형태로 보내줬으면 좋겠다.’ 라는 것 또한 없었기에

1차 프로젝트때 front를 했던 경험을 살려 front가 사용하기 편한 형태로 API를 만들었다.

그리고 front분들이 ‘어떻게 요청을 날려야하는지를’ 알기위해 back의 code를 보며

시간을 허비하는것을 막기위해 각 API마다 명세서를 파일로 만들어서 Slack방에다가 공유하였다.

(추첨 API.md의 내용)

위와같이 API 명세서를 만들어 front에게 전달하니

나의 의도를 상세히 말할 수 있었고 상대방 또한 빠르게 이해했다.

프론트입장에서 API형태를 요청을 날리지 않아도 알 수 있었고

back을 신경쓰지않고 작업에 몰두할 수 있게되어 좋았다고 한다.

🤔 [회고-3] SQL을 좀 더 공부해보자

이번 프로젝트를 하면서 SQL로 할 수 있는것이 생각보다 많다는 것을 알게되었다.

지금까지 Dao단에서는 기초적인것들로 구현하고 모든 가공을 Service단에서 처리하였는데

그러다보니 쓸데없는 DB의 접속이 늘었고 코드 또한 가독성이 좋지 않았다.

이러한 부분을 코드리뷰로 지적받아 구글링을 하다보니 ‘쿼리문으로 이런것도 할 수 있어?’ 라는 생각과 함께 나의 무지함을 알게되었다.

초급수준인 나에겐 그 깊이는 아득했기에 한동안 정보의 늪에 빠져 약간의 좌절감에 빠져있었다.

하지만 이제 시작하는 단계임을 인정하자 마음이 조금 편해졌고 매일 새롭게 알게되는 쿼리문을 정리하기로 마음먹었다.

🧑‍💻 Backend (Just Do It)

아쉽게도 2차 프로젝트 또한 e-commerce사이트를 코딩하게 되어 새로운 기능을 많이 추가하지는 못하였다. 하지만 1차 프로젝트에서는 하지 못했던 "예외처리 및 HTTP STATUS CODE, Unit Test" 등을 적극 활용하여 완성도 높은 API를 만들기 위해 노력하였다.

- 사전 DB 모델링 -

기본적으로 e-commerce사이트 특징인 products가 중심이 되어 대부분의 table이 연결되었고

나이키는 필터기능이 상당히 많기에 그에 맞게 table이 나눠져 있는것을 볼 수 있다.

나이키는 한가지 특징이 있는데 그것은 바로 추첨(Draw)기능이다.

추첨을 하기 위한 상품은 장바구니에도 들어가지 않으며 댓글또한 달 수 없기에

products가 아닌 snkrs table에 따로 담아 특별취급하였다.

또한 추첨기능을 구현하기위해 추첨을 한 사람들을 관리하는 table인 snkrs_data

당첨된 사람들을 관리하는 table인 snkrs_winners를 만들었다.

Detail API

---

models/productDao.js

const getProductData = async style_code => {
  return await prisma.$queryRaw`
    SELECT
      products.style_code,
      products.name,
      categories.name as category,
      product_colors.name as color,
      product_colors.color_hex as hex,
      product_genders.name as gender,
      normal_price,
      sale_rate,
      sale_price,
      is_member,
      sub_icon.name as shoes_type,
      sub_brand.name as brand,
      sub_clothes.name as clothes_type,
      sub_accessories.name as acc_type,
      (
        SELECT JSON_ARRAYAGG(JSON_OBJECT('url', product_img_urls.name, 'is_main', is_main))
        FROM product_img_urls
        JOIN products ON products.style_code = product_img_urls.style_code
        WHERE product_img_urls.style_code = ${style_code}
      ) AS img,
      (
        SELECT JSON_ARRAYAGG(JSON_OBJECT('size', product_sizes.name, 'quantity', product_with_sizes.quantity))
        FROM product_with_sizes
        JOIN products ON products.style_code = product_with_sizes.style_code
        JOIN product_sizes ON product_size_id = product_sizes.id
        WHERE product_with_sizes.style_code = ${style_code}
      ) AS info
    FROM
      products
    JOIN
      categories ON category_id = categories.id
    LEFT JOIN
      product_colors ON color_id = product_colors.id
    JOIN
      product_genders ON gender_id = product_genders.id
    LEFT JOIN
      sub_icon ON sub_icon_id = sub_icon.id
    LEFT JOIN
      sub_brand ON sub_brand_id = sub_brand.id
    LEFT JOIN
      sub_clothes ON sub_clothes_id = sub_clothes.id
    LEFT JOIN
      sub_accessories ON sub_accessories_id = sub_accessories.id
    WHERE
      products.style_code = ${style_code};
  `;
};

상품의 디테일 정보를 가져오는 쿼리문이다.

하나의 제품에 4개씩 있는 이미지와 10개씩 있는 사이즈를 ‘어떻게 객체화 시켜서 가져올까?’에 대해 많이 고민했었다.

처음에는 GROUP_CONCAT과 CONCAT으로 [,]으로 배열의 모양을 만들고 그것을 {,}로 객체를 만들려고 하였다.

어찌저찌 만들긴 하였으나 재활용하기에는 너무나 코드가 가독성이 떨어지고 복잡해보였다.

그러던중 JSON을 사용하여 손쉽게 배열과 객체를 만들 수 있다는 것을 구글링을 통해 알아냈다.!

JSON_OBJECT으로 각 데이터를 객체화 시키고 JSON_ARRAYAGG을 통해 배열로 만들어준다.

생각보다 사용법도 간단하고 결과물도 좋아서 자주 사용할 것 같다.

{
    "message": "성공",
    "data": {
        "style_code": "AAA-0001",
        "name": "나이키 에어포스 1 GORE-TEX",
        "category": "shoes",
        "color": "주황색",
        "hex": "#EB621D",
        "gender": "남성",
        "normal_price": 189000,
        "sale_rate": null,
        "sale_price": null,
        "is_member": 0,
        "shoes_type": "에어 포스 1",
        "brand": "나이키 스포츠웨어",
        "clothes_type": null,
        "acc_type": null,
        "img": [
            {
                "url": "/Images/Men/Shoes/Airforce/1/1-1.png",
                "is_main": 1
            },
            {
                "url": "/Images/Men/Shoes/Airforce/1/1-2.png",
                "is_main": 0
            },
            {
                "url": "/Images/Men/Shoes/Airforce/1/1-3.png",
                "is_main": 0
            },
            {
                "url": "/Images/Men/Shoes/Airforce/1/1-4.png",
                "is_main": 0
            }
        ],
        "info": [
            {
                "size": "220",
                "quantity": 80
            },
            {
                "size": "230",
                "quantity": 80
            },
            {
                "size": "240",
                "quantity": 80
            },

          ...

        ]
    }
}

Cart API

---

모두다 설명할 수 없으니 Cart API의 한 부분인 Create 부분만 보도록 한다.

middleWare/authorization.js

const authentication = async (req, res, next) => {
  try {
    const token = req.body.user_id;
    const validToken = verifyToken(token);

    if (validToken) {
      const [check] = await userDao.isExistUser(validToken.id[0].id);
      const isExsitUser = new IsExistItem(check, resultType, 404);
      isExsitUser.notExistErr('존재하지 않는 UserId 입니다.');
      req.body.user_id = validToken.id[0].id;
    } else {
      const err = new Error('토큰이 유효하지 않습니다.');
      err.status = 401;
      throw err;
    }
    next();
  } catch (err) {
    res.status(err.status || 500).send({ message: '실패', err: err.message });
  }
};

클라이언트가 user_id를 갖는 토큰을 담아 요청을 보내면

토큰을 확인하여 유효한지 확인하고, 유효하지 않다면 인증에러인 401을 띄운다.

또한 토큰은 유효하지만 DB에 없는 user라면 자원이 존재하지않는다는 뜻이므로 404에러를 띄운다.

utils/err.js

class RequiredKeys {
  constructor(REQUIRED_KEYS) {
    this.REQUIRED_KEYS = REQUIRED_KEYS;
  }
  verify() {
    for (let key in this.REQUIRED_KEYS) {
      if (!this.REQUIRED_KEYS[key] && this.REQUIRED_KEYS[key] !== 0) {
        const err = new Error(`${key} 정보가 올바르지 않습니다.`);
        err.status = 400;
        throw err;
      }
    }
  }
}

class AffectedRow {...} // 생략

class IsExistItem {...} // 생략

export { RequiredKeys, AffectedRow, IsExistItem };

자주 사용되는 에러함수들을 캡슐화 하여 관리하였다.

하나로 합칠까 생각하였지만 일단은 각각 나눠놓았다.

(너무 길어지므로 나머지는 생략)

controllers/cartControllers.js

const createCart = async (req, res) => {
  try {
    const { style_code, user_id, size, quantity } = req.body;
    const REQUIRED_KEYS = { style_code, user_id, size, quantity };

    const keys = new RequiredKeys(REQUIRED_KEYS);
    keys.verify();

    const result = await cartServices.createCart(
      style_code,
      user_id,
      size,
      quantity
    );

    res.status(201).send({ message: '성공', result });
  } catch (err) {
    res.status(err.status || 500).send({ message: '실패', err: err.message });
  }
};

컨트롤러단에서는 클라이언트가 요청에 필요한 값들을 제대로 넣었는지 유효성 검사를 하고

아니라면 400에러를 띄우도록 했다.

성공시에는 201코드로 반환해주었다.

services/cartServices.js

import { cartDao, productDao } from '../models';
import { resultType } from '../type';
import { IsExistItem } from '../utils/err';

const createCart = async (style_code, user_id, size, quantity) => {
  const [check] = await cartDao.checkCart(style_code, user_id, size);
  const [checkSize] = await productDao.isExistSizes(style_code, size);
  const [checkStyleCode] = await productDao.isExistStyleCode(style_code);

  const isExistStyleCode = new IsExistItem(checkStyleCode, resultType, 404);
  isExistStyleCode.notExistErr('유효하지 않는 styleCode 입니다.');

  const isExistSize = new IsExistItem(checkSize, resultType, 404);
  isExistSize.notExistErr('유효하지 않는 size 입니다.');

  const isExistItem = new IsExistItem(check, resultType, 409);
  isExistItem.existErr('이미 품목에 있습니다.');

  await cartDao.createCart(style_code, user_id, size, quantity);

  const data = await cartDao.getCartList(user_id);

  return data;
};

이미 Create된 제품이라면 409에러를 띄우도록 하였다.

서비스단에서는 한번더 요청에 대한 값을 유효성 검사하여 404에러를 띄우도록 했다.

사실 404에러들을 한곳에 모아 middleWare로 만드는게 더 좋을것 같았지만

팀원들과 사전합의가 되지않은 상황에서 독단적으로 할 수가없어 이대로 두었다.

그리고 카트에 Create가 성공했을시

프론트에서 카트리스트를 보여주는 API를 또 요청하는것이 귀찮을수도(또는 어려움이) 있을것 같아

getCartList를 return 해주었다.

models/cartDao.js

import { PrismaClient } from '@prisma/client';
import { createType, updateType, deleteType } from '../type';
import { AffectedRow } from '../utils/err';

const prisma = new PrismaClient();

const createCart = async (style_code, user_id, size, quantity) => {
  await prisma.$queryRaw`
    INSERT INTO
      carts(
        style_code,
        user_id,
        size,
        quantity
      )
    VALUES
      (
        ${style_code},
        ${user_id},
        ${size},
        ${quantity}
      );
  `;

  const [row] = await prisma.$queryRaw`
    SELECT ROW_COUNT() as result;
  `;

  const newRow = new AffectedRow(row, createType, 409);
  newRow.result();

  return;
};

사실 이부분을 넣을지 말지 고민했다.

하지만 보다 완성도 높은 API를 만들기 위해

Create된 후 Affected Row가 1이란 값을 제대로 뱉어내는지 확인을 했다.

만약 제대로 row가 생성되지 않았다면 409에러를 띄우도록 했다.

아직 이부분은 50%밖에 완성이 되지않았다.

어떤 이유에서든지 만약 row가 2개 생겼을 시 에러를 띄우겠지만

이미 그 값은 table에 들어갔을 것이다.

그러므로 추후 TRANSACTION을 통해 에러가 발생되면 ROLLBACK 시키는 로직을 추가할 것이다.

Draw API

---

나이키의 꽃 추첨기능이다.

server.js

const lottoSchedule = async () => {
  const list = await snkrsDao.getSnkrsList();
  let isOpen = false;

  for (let i = 0; i < list.length; i++) {
    cron.schedule(`00 09 * * *`, async () => {
      isOpen = true;
      await snkrsDao.updataOpenClose(isOpen, list[i].style_code);
      console.log('시작');
    });

    cron.schedule(`${(i + 1) * 5} 30 09 * * *`, async () => {
      isOpen = false;
      await snkrsDao.updataOpenClose(isOpen, list[i].style_code);
      await snkrsServices.selectWinner(list[i].style_code);
      console.log('마감');
    });
  }
};

snkrs 제품들은 매일 09:00 ~ 09:30에 추첨을 할 수 있다.

처음에는 mysql table의 칼럼의 값을 어떻게 시간으로 제어 할 수 있을지 막막하였다.

하지만 다행히도 구글링해보니 소스는 많았다.

Event Scheduler, Cron 등 다양한것이 있었지만

node에서 지원해주는 node-cron이란것이 있다는 것을 알게되어 이것을 활용하기로 했다.

위의 함수는 정해진 시간에 snkrs 제품들의 추첨여부가 변경되고 당첨자를 뽑게하는 기능이다.

services/snkrsServices.js

const createUsersToLottoBox = async (user_id, style_code, size) => {
  const [snkrs] = await snkrsDao.getSnkrsData(style_code);
  const [checkStyleCode] = await snkrsDao.isExistStyleCode(style_code);
  const [checkSize] = await snkrsDao.isExistSizes(style_code, size);

  const isExistStyleCode = new IsExistItem(checkStyleCode, resultType, 404);
  isExistStyleCode.notExistErr('유효하지 않는 styleCode 입니다.');
  const isExistSize = new IsExistItem(checkSize, resultType, 404);
  isExistSize.notExistErr('유효하지 않는 size 입니다.');

  if (snkrs.is_open === statusType.OPEN) {
    const [check] = await snkrsDao.checkUserLottoBox(user_id, style_code);

    const isExistItem = new IsExistItem(check, resultType, 409);
    isExistItem.existErr('이미 추첨을 하셨습니다.');

    await snkrsDao.addLottoBox(user_id, style_code, size);
    await snkrsDao.addWinnerBox(user_id, style_code, size);

    return;
  } else if (snkrs.is_open === statusType.CLOSE) {
    const err = new Error('추첨기간이 아닙니다');
    err.status = 409;
    throw err;
  }
};

바로 서비스단에서 설명을 하겠다.

우선 프론트에서 ‘응모하기’버튼은 제품의 is_open이라는 값에 의해 active가 결정된다.

그리고 백에서도 is_open값에 따라 추첨가능여부를 판단한다.

추첨시간이 되어 사용자가 ‘응모하기’버튼을 눌러 요청을 보내면 요청에 대한 유효성 검사를 한다.

검사에 이상이 없다면 ,

addLottoBox, addWinnerBox함수를 통해 DB의 snkrs_data, snkrs_winner 테이블에 데이터를 저장한다.

(Dao단에서는 Affected Row를 통해 제대로 생성이 되었는지를 확인하고 아니라면 에러를 띄우는 코드가 존재한다.)

services/snkrsServices.js

const selectWinner = async style_code => {
  const [check] = await snkrsDao.checkUserWinnerBox(style_code);
  const [count] = await snkrsDao.getCount(style_code);
  const participants = await snkrsDao.getNumOfParticipants(style_code);

  if (check.result === resultType.EXIST) {
    const [winnerInfo] = await snkrsDao.selectWinner(style_code);

    await snkrsDao.updateCount(
      winnerInfo.style_code,
      count['MAX(count)'] + 1,
      participants.length
    );

    await snkrsDao.updateWinner(winnerInfo.style_code, winnerInfo.user_id);
    await snkrsDao.deleteLottoBox(style_code);

    return;
  } else {
    return;
  }
};

당첨자를 뽑는 코드이다.

checkUserWinnerBox함수를 통해 snkrs_winner에 데이터 유무를 확인하고 만약 아무값도 없다면

아무도 응모하지 않은 것이므로 그냥 return 된다.

한명이상 응모를 했을시 selectWinner함수를 통해 랜덤으로 1명을 뽑는다.

당첨자가 정해지면 updateCount를 통해 해당회차에 응모한 사람만큼만 n+1회차로 업데이트 시켜준다.

마지막으로 당첨자가 뽑혔으니 임시로 응모한 사람들을 저장했던 snkrs_data 테이블은 삭제시켜준다.

(Dao단에서는 Affected Row를 통해 해당 상품에 참가한 인원만큼 데이터를 삭제시켰는지 확인하는 코드가 존재한다.)

보러가기 ⬇️

1차 프로젝트 회고록