금오공대 벼룩시장 후기

oune·2023년 2월 26일

restapi 문서 미들웨어 배포 보안 서버리스 실사용 테스트 프로젝트

기술스택

view.js, react, node.js, express, firebase...

파트 분배

백엔드 2명, 프론트엔드 4명
유저 프론트엔드 2명, 관리자 프론트엔드 2명 으로 나뉘어서 개발을 진행했습니다.
이중 백엔드파트에 내가 대부분의 작업을 맡아서 하게 되었습니다.

개발 기간

3주간의 기간이 주어 졌고, 2학년 말이였기에 기술력이 조금 부족 했기 때문에 최대한 단순하게 개발 목표를 잡아서 진행했습니다.

컴공, 컴소공 학생회와 복지위원회, 협동조합이 함께 진행하는 프로젝트 였기에
문서를 남기면서 진행, 요구사항 분석, 설계 를 진행하게 회의를 통해서 결정함.

왜 서버리스를 사용하였나.?

3주간의 개발기간이 주어진 상황에서 교내 다른 서버 배표하기엔 교내 서버를 이용하는데 필요한 절차들과 추가적인 테스트가 부담이였기때문에 교내 서버를 이용하는 것은 불가능하였고,
학과 서버를 이용 하는 것은 학과 서버에서 방화벽등 같은 문제가 있었고, 성능이 일반적인 데스크탑 정도의 성능이였기 때문에 혹시나 이용자가 몰리게 되면 서버가 버티지 못할 가능성이 있었습니다.

사용자들이 벼룩시장이 개최되는 3일동안만 주로 사용하는 프로젝트 특성상 서버리스로 가닥을 잡고 진행함. 서버 비용에 대한 걱정으로 도서의 사진을 올리지 않고 텍스트만 업로드 하도록 개발하여 이미지를 올리는 서버 비용을 줄일수 있게 되었습니다.
결과적을 으로 3일간 서버를 공개하는데 5천원 정도의 비용이 발생하는 정도로 마무리 되었습니다.

Restapi

api를 설계하는데 사용하고, 개발하는데 명확하고 간단하게 설계하는 것이 중요했다. 그렇기에 restfull 하게 설계하도록 노력하면서 진행하였다.

미들웨어

클라이언트에서 요청할때 요청한 json의 key가 올바르지 않아서 생기는 문제가 종종 있었다. 그렇기에 미들웨어로 필요로 하는 필드나, 불가능한 필드를 확인하는 것을 만들어서 누락된 필드가 존재한다면 errer를 발생하도록 개발을 하였다.

function requireField(fields) {
    // eslint-disable-next-line consistent-return
    return (req, res, next) => {
        const fails = [];
        for (const field of fields) {
            if (!req.body[field]) {
                fails.push(field);
            }
        }

        if (fails.length >= 1) {
            const be = (fails.length === 1) ? "is" : "are";
            return res.status(400).send(`${fails.join(',')} ${be} required`);
        }

        next();
    };
}

문서화

postman 기능을 이용하여 입력, 출력, 에러메시지 예시들을 기록하고, 테스트 하면서 진행하였다. 문서를 공유함으로써 프론트 엔드 개발자분들이 확인할 수 있도록 하였다.

NoSql 설계 하면서

모든 상황보다 현재 상황에 맞도록 설계

처음 보유 도서의 목록을 데이터 베이스로 설계 했을때 도서 상태가 동적으로 추가가능하도록, 문서를 분리하는 방향으로 설계를 진행해야 했던 상황이였습니다.
하지만 문서를 분리하면서 요청이 늘어나면서 발생이 가능한 비용과 기존의 프론트엔드파트에서 수정사항을 원하지 않았고, 도서 상태의 종류가 다들 비슷비슷하고, 변경하는 일이 적다는 판단에 도서 상태의 종류를 4가지로 고정하는 것으로 설계하였습니다.

비용절감

기존의 쿼리 중에서 여러 document에서 접근하여 요청을 처리 하는 경우가 존재하였다. 통합하게 도니다면 갱신이상이나, 삭제이상이 발생할 가능성이 존재했지만. 그렇게 중요한 부분은 아니였고, 이상이 발생하는 가능성도 낮은 부분이였기에 통합하여 데이터베이스로 향하는 요청중 20% 정도를 줄일수 있었다.

테스트는 많이많이

테스트를 제대로 하지않아서 생겼던 이슈들을 소개하고자 합니다. 개발하는 자신을 믿지 말고 다양하고 많은 테스트케이스를 추가 하고 테스트를 거쳐야 개발하면서 생기는 문제를 줄일수 있습니다.

날자 이슈

2회차 벼룩시장을 배포하고 모니터링중 기존에 오픈 시간에 오픈이 되지 않는 문제가 발생하게 되었습니다. 우선 에브리타임과 같은 커뮤니티에 상황을 알리고 프론트엔드를 수정하여 변경된 오픈 날자로 안내하고, 문제 상황을 확인하게 되었습니다.
문제원인은 프론트엔드에서 시간을 확인한뒤 요청을 보내게 되는 상황에서 기존의 개발자가 인수인계를 한뒤 새로운 개발자분이 시간을 수정했는데, 기존 라이브러리에서 사용하는 날자 방식이 YYYY-MM-DD 가 아닌 다른 포맷을 사용했던터라, 포맷에 맞게 날자를 수정하여 해결하게 되었습니다.

도서명 검색 대소문자 확인

기존에 검색 기능을 테스트할때 전부 한글로 된 도서명을 검색했던 터라 영어를 테스트할 생각을 못했었는데, 영어 대소문자를 구별했기에, 검색 결과에서 나타나지 않는 문제가 발생했었습니다.

보안

프로젝트를 진행하면서 신경 쓰고 고민했던 보안 관련 내용들 입니다.

비밀번호는 암호화

실제로 사용자 들이 사용하는 프로젝트 였기에 비밀번호는 서버에 해싱된 상태로 저장하도록 하였습니다. bcrypt를 사용하여 해싱하여 저장하도록 함. 아무도 사용한 비밀번호가 뭔지 알수 없도록 개발 했습니다.
계정의 비밀번호가 아니였기 때문에 비밀번호 변경 등은 따로 문의해서 해결하도록 조치를 하였습니다.