whenever purple

🍞 N빵 소개

설명:  혼자사는 것보다 같이 구매하면 더 이득이라면?! 이웃과 함께 구매할 수 있는 공동구매 커뮤니티 서비스입니다.

제작: 2022.04.22 ~ 2022.06.02 

👉 N빵 서비스 바로가기    https://www.nbbang.site/

📌 노션 바로가기

시연영상: 🎬서비스 시연 및 발표 영상 보러가기

깃허브: Front Github  /  Backend  Github

📐 아키텍처

⚒️ 기술스택

📖 라이브러리

🔎 핵심기능

✅ 지도 (kakao Map)

• 사용자 위치 기준, 권역별 게시글 확인가능
• 지도 마커 선택시, 해당 게시글의 상세 내용을 보여주며 위치로 이동

✅ 채팅 (Socket.io)

• 각 게시물에 따른 채팅방 생성
• 상대방이 채팅 입력시, ‘입력중’이라는 상태 확인 가능
• 상대방이 입장/퇴장시 확인 가능
• 채팅창 상단에 위치 시, 새로운 채팅메세지를 스크롤다운 없이 확인가능

✅ 참가자 추가기능

• 실시간으로 채팅 참여자 확인 가능
• 방장은 대기자 ⇄ 거래자로 변경 가능
• 거래자인 경우 취소 가능

✅ 알림 (Socket.io)

• 해당 채팅방에 있지않거나 오프라인 상태시, 알림 송신
  • 새로운 메시지 전달시
  • 해당 게시글에 거래자로 확정시
  • 거래자가 거래취소시
  • 거래 확정후 리뷰작성 요청시

✅ 게시글 제목 기준으로 검색 가능

✅ 마이페이지에서 내정보 조회 가능

• 본인이 작성한 공구 / 참여한 공구 / 찜한 공구를 확인 가능

✅ 마이페이지에서 내 정보 변경 기능

• 프로필 사진 / 닉네임 / 상태메시지 변경가능
• 회원 탈퇴 가능

✅ 글 작성자의 공구후기 확인 기능

• 작성자의 마이페이지에서 공구 후기 확인 가능

🧩 ERD

🥖 API 설계

✨ API 설계 자세히보기

🚨 이슈 및 트러블 슈팅

리사이징으로 썸네일 이미지 생성

도입이유

• 사이드 바, 상세모달, 채팅, 지도 모달과 같이 많은 이미지가 뜨게 되는데 사용자가 불편함을 느끼지 않고 빠르게 정보를 조회할 수 있도록 하기 위함

선택지

실전 프로젝트 회고

프로젝트를 진행하면서 내게 제일 도전적인 기능은 채팅기능이였다.

다대다의 채팅 기능은 채팅의 제일 기본적인 기능이였기에 큰 문제 없이 연결되었다. 

하지만,

회원 비로그인시 또는 채팅방에서 나갔을 때 실시간으로 메세지알림을 주기 위해

해당 회원의 socket.id가 언제 생기고 언제 사라지는지를 직접 확인해봐야했다.

회원이 채팅방에 들어오면서 받는 socket.id는

브라우저를 새로고침하면 socket.id가 지속적으로 변경이 되었다. 

그래서 socket.id와 회원의.ID를 지속적으로 확인할 수 있게 db에 저장했고,

매번 채팅방에 들어올때마다 socket.id를 새로 고쳐줬다.

Websocket 과 socket.io를 정확이 구분을 못지었던 것같아 간략하게 이 둘의 차이점을 찾아보았다. 

Websocket 과 socket.io 차이점
Websocket은 양방향 소통을 위한 포로토콜이다.
프로토콜은 쉽게 말하자면, 서로 다른 컴퓨터끼리 소통하기 위한 약속 정도로 이해하면 된다.
 
반면, Socket.io는 양방향 통신을 하기위해 웹소켓 기술을 활용하는 라이브러리이다.
어찌보면 자바스크립트의 jQuery의 관계가 비슷하다고 할 수 있다. 그렇기 때문에 socket.io가 같은 기능을 구현하더라도 약간 느리지만, 많은 편의성을 제공한다. 또한, java, C++, Python 등 여러 언어들의 라이브러리 또한 지원한다.

Socket.io 라이브러리 안에 websocket이 있고,

socket.io 가 websocket보다 (지금은 많은 차이는 없지만) 호환이 잘 되기 때문에 잘 사용한 것같다.

Websocket
-      HTML5 웹 표준 기술
-      매우 빠르게 작동하며, 통신할 때 아주 적은 데이터를 이용함
-      이벤트를 단순히 듣고, 보내는 것만 가능함

Socket.io
-      표준 기술이 아니며, 라이브러리임
-      소켓 연결 실패 시, fallback을 통해 다른 방식으로 알아서 해당 클라이언트와 연결을 시도함
-      방 개념을 이용해 일부 클라이언트에게만 데이터를 전송하는 브로드캐스팅이 가능함

프로젝트 끝났으니깐, 말하는 아쉬운점.

하지만, 생각보다 더 많은 기능들을 도전하지 못했던 것이 너무 아쉽다.

프로젝트가 마무리되면서, 점점 서버에 대한 고민이 시작됬다.

'서버는 잘 작동이 되고 있는건가?'

'채팅을 사용하면 데이터가 미친듯이 쌓일텐데, 괜찮은건가?'

'사람들이 몰려와도 내 서버는 잘 버틸 수 있는가?'

'대체 어떻게 하면 그 결과를 볼수 있지?'

그 중 제일 아쉬운 것은 Nignx로 IP차단

배포를 시작하고 나니, 무자비하게 채팅을 하거나 테스트게시물을 올렸다. 그것 말고도 서버를 나쁜의도로 사용하기 위해 들어오기 때문에 IP차단이 필요하다고하여 IP차단을 염두해두고 있다.

Nginx로 IP 차단하려고 했지만, Nginx의 reverse port 가 적용이 안되서 사용된 포트라고 이슈를 뿜어내더니 결국에는 

'ERR_CONNECTION_REFUSED' 에러가 났다. SSL인증을 했는데도 나는 에러면 웹 시간이 맞지 않아서 나는 에러였다.

이 문제를 해결하려면 프론트분들한테 요청을 드려야했던 것같은데, 이것도 확실하지 않고 다음날의 최종 발표회에 준비하기 위해서 마무리를 지었다. 여러모로 이것저것 시도할 수 있는 시간들이 충분하지 않아 아쉬웠다.

어떤 개발자가 되고 싶은가

백엔드의 가장 큰매력은 결과를 수치로 볼 수 있는 것이 아닌가 싶다.

결과 값을 보기 위해서 그에 따른 엄청난 공부가 필요하겠지만

결과 확실히 있는, 데이터로 보는 개발자가 되고 싶다.

N빵

위치기반 공동구매 플랫폼 'N빵'입니다.<N빵>은 혼자사는 것보다 같이 구매하면 더 이득이라면?!
이웃과 함께 구매할 수 있는 공동구매 커뮤니티 서비스입니다.
자신의 주변에있는 공구 게시글을 작성해보고, 참여해 보세요:)더 좋은 서비스로 개선해나가기위해 피드백 이벤트를 진행중입니다.

많은 관심과 참여부탁드립니다!

5월 25일 ~ 6월 1일 (23시 59분)까지 공구게시글에 참여하시거나,
피드백을 작성해주신 분들에게는 추첨을 통해 치킨3마리와 메가커피 기프티콘 50잔을 빵빵 쏩니다!
당첨자 발표 및 상품 발송은 2022년 6월 2일 순차적으로 발송할 예정입니다

N빵 URL : https://nbbang.site

        Back-end(Node.js) : 장윤아, 오경은, 한재혁
        Front-end(React) : 권영민, 곽진호, 장수찬
        Designer(UI/UX) : 김원경, 이화정

웹 페이지와 모바일로도 확인가능합니다 :)

5주차 한일!

- 소켓/ CRUD 버그 수정 및 서비스배포

- 테스트 서버 연결

- 마켓팅, 유저피드백 반영

유저피드백 및 수정사항

1. 인터넷이 느릴 경우 글 등록하기를 여러번 누를 수 있는 현상이 있음

(게시글이 중복하여 생김)

2. 가격, 인원, 제목, 상세위치, 내용, 채팅 글자 수 제한

3. 설명페이지의 잘못된 이미지 변경

4. 비로그인 상태로 메인페이지 접근 시 바로 설명 페이지 보여주기

(설명페이지가 미흡하다는 의견이 있어 추가할 예정)

5. 게시물 카테고리 추가

6. 오른쪽 하단의 시/구/동 버튼을 누를 경우 해당 레벨에 맞게 화면 범위 설정

7. 채팅 유저리시트에서 외부를 클릭했을 경우 닫히게 설정

8. 브라우저 탭 상단의 배경이 흰색일 경우 로고가 보이지 않아, 색상 조정

9. 게시글이 없을 경우 생성되는 문구의 간격 조정

0. 채팅창에서 이용자가 이전 내용을 보고 있을 경우 새로운 메세지를 토스트메시지 형식으로 제공

11. 후기 서비스 (구현중)

12. 유저정보수정 (구현중)

13. 회원탈퇴 (구현중)

3주차 한 일!

3주차에는 실전프로젝트에 대해서 중간점검을 해야했다. 

우리가 최소 기능 구현하기로 했던 것들을 마무리하고 정리했다.

중간발표 시, (또는 인터뷰시) 알아두면 좋았을 것들.

- Websocket 과 socket io 의 차이점?

- 엔진엑스를 사용하는 이유는?

- HTTP 와 HTTPS 의 차이점? (HTTPS의 이점은?)

2주차에 한일!

완료된 로그인, 회원가입 API를 배포하여 프론트와 연결하는 작업을 했다. 

여유가 생겨 회원가입 인증코드 라이브러리(nodemailer)를 추가했다. 

회원가입을 하려면 인증코드가 필요하게 되서 번거롭게 됬다.

기획단계에서 socket관련 지식이 없으니 API를 추가한다거나 이벤트 이름을 설정하지 않았었다.

또한, mysql 에 채팅관련한 테이블을 추가했고, 소켓을 배포된 환경과 연결을 시켰다. 

메인페이지같은 경우, 프론트에 필요한 데이터를 지속적으로 추가되어

지속적으로 바뀌었다. 그만큼 Mysql을 쿼리문의 Inner Join, 새로운 group 생성하여 다시 적용했다.

Mysql 스케줄러를 통해서 1분마다 게시판 종료시점을 지난 경우, 완료된 상태로 자동화 시켰다.

또한, 이메일로 보내지는 인증코드는 DB에 저장되고 있어 5분마다 삭제되어 DB의 용량이 과부화 되지 않게 하였다.

2주차: 기술적인 이슈와 해결

이슈1. Mysql 에러, Error Code: 1071. Specified key was too long; 

Mysql에서 Primary Key(PK)를 여러개 설정 할 수 있다는 말에,

유저 고유번호, 이메일, 닉네임, 심지어 이미지까지 설정을 했다. 

하지만, 이미지같은 경우 Varchar(5000)으로 설정해둔 상태였다. 

총 PK의 문자길이가 제한이 되어있는데, 그 길이보다 더 길어져서 생긴 문제였다. 

이미지를 PK에서 제외하니, 해결되었다. 

프로젝트: Slack (클론 프로젝트)

설명: Socket 기능구현을 위해 Slack을 클론코딩하였습니다. 

제작: 2022.04.15~2022.04.21

시연영상: https://www.youtube.com/watch?v=nZWXoWw93bg&t=1s 

깃허브: Frontend Github / Backen Github

노션: https://zircon-dolphin-2d9.notion.site/7cf89428eab0438abb8e85dab3e734b0

사용기술

• Server: AWS EC2 (Ubuntu 18.04 LTS)
• Framework: Express (Node.js)
• Database: MongoDB (Mongoose)
• JWT (Json Web Token)
• Joi
• Bcrypt
• CORS
• Multer
• Front-end: React

핵심기능

• 로그인페이지
  • 아이디, 패스워드 입력 가능
  • 로그인 시, 토큰전달 (모든페이지에서 해당 토큰확인)
  • 이메일 형식 확인 가능
  • 아이디/닉네임 중복검사 가능
  • 비밀번호 재확인 일치하는지 확인 가능
• 채널페이지
  • 채널 조회, 생성, 수정, 삭제 가능
  • 채널 내 내용 조회, 생성, 수정, 삭제 가능 (수정시, 편집됨 표시)
  • 내용 내 코멘트 조회, 생성, 삭제 가능
• 다이렉트메시지 페이지
  • 친구들과 실시간 채팅 가능

Trouble Shooting

▶몽구스의 contentId 생서시,  Math.random()을 사용했으나 몽구스에 숫작가 온전히 저장되지 않아 해당 데이터를 찾을 수가 없었다. 

→ Math.random()에 나타난 난수를 글자로 바꾸어 짧은 id를 만들었다.

Math.random().toString(36).substr(3)

▶채널 내 ContentList에서 선택된 content만 삭제하려고 했지만 Delete 사용시 내용 전체가 없어졌다. 

→ 삭제가 아닌 선택한 내용을 제외한 나머지 내용으로만 업데이트할 수 있게 수정되었다.

4월 22일 금요일부터

드디어 나의 첫 항해 99 실전 프로젝트가 시작되었다!

이전 프로젝트와 다르게 6주를 진행하다보니,

프로젝트를 실제 사용되는 사이트처럼 좀더 디테일하게 구현해야할 것같다.

미래의 백엔드 개발자로서,

이번 프로젝트에서는 유지, 관리에 용이한 프로젝트로 만드는데 

좀더 집중해야할 것같다

1주차에 한일!

처음 기획한 사이트는 기부관련 웹사이트였다.

 결제시스템을 도전해보고 싶어서 기획하였는데,

"결제시스템이 되는지 안되는지 확인하라" 라는 멘토님 리뷰에

하지말라는 말인지 이해를 못하고... 3일동안 진짜 실현하는 방법만 찾아봤더랬다..

기획멘토링미팅에서 멘토님과 직접 이야기를 하고서는,

우리가 기획한 프로젝트가 개발자로서 보여줄 기능도 충분하지 않으며, 

실제 프로그램을 런칭한다고 가정했을때, 충분히 좋은 소재가 아님을 깨닭았다..... 

부랴부랴 두번째 프로젝트를 기획하고 개발을 시작했다. 

처음 기획했던 소재가 와이어프레임, API명세서 작성이 꽤 빨리 끝났기에 

Mysql DB연결도 하고, 쿼리로 직접 코드도 작성하기도 했었다.

그래서 두번째 기획된 주제가 확정되면서

하루만에 와이어프레임, API명세서, 디자인레이아웃까지 끝냈다. 

(배우지 않았던 기능을 시도한 기능들은 와이어프레임과 API명세서는 제외되었다.)

 나머지 2일은 로그인과 회원기능을 REST API 기능구현을 완료했고

해당 부분에 대해서는 https로 배포를 완료하였다. 

1주차: 기술적인 이슈과 해결!

이번 프로젝트에서는 웹사이트의 데이터 보안을 위해 HTTPS 를 사용하게 되었다. 

HTTPS란?
HTTPS는 하이퍼 텍스트 전송 프로토콜 보안(Hypertest Transfer Protocol Secure)의 약자이다. 
일반 HTTP 프로토콜은 서버에서부터 브라우저로 전송되는 정보가 암호화되지 않는 문제점이 있다. 그래서 터이터가 쉽게 도난당할 수 있다. HTTPS 는 SSL(보안 소켓 계층)을 사용하여 이 문제점을 해결했다. 

SSL은 서버와 브러우저 사이에 안전하게 암호화된 연결을 만들 수 있게 도와주고, 서버 브라우저가 민감한 정보를 주고받을때 이것이 도난 당하는 것을 막아준다. 데이터를 암호화하여, 도난을 당하더라도 암호화되어있기 때문에 해독할 수 없다. 

HTTPS 연결은 아래의 블로그를 참고하였습니다.

https://velog.io/@xkskxhtm96

이슈 1. crbug/1173575, non-JS module files deprecated.

<해결방법>

*윈도우 터미널(cmd) 아래와 같이 작성후, 컴퓨터 전원을 껏다가 켠다.

ipconfig/release

ipconfig/renew

ipconfig/flush DNS

해결되는가 싶더니, 깃배쉬에서 port 오류로 배포가 되지 않았다.

이슈 2. http에서 https로 포트포워딩이 안될때

<해결방법>

*깃배쉬에 작성, 모든 포트를 삭제하면된다.

1. 포트포워딩 확인하는 명령어 

sudo iptables -t nat -L --line-numbers

2. 포트포워딩 삭제 명령어 (갯수만큼 반복한다)

sudo iptables -t nat -D PREROUTING 1

3.  포트포워딩 확인하는 명령어 (삭제되었는지 확인한다.)

sudo iptables -t nat -L --line-numbers

아래의 블로그를 참고하였습니다.

https://kelly-tech.tistory.com/32

프로젝트: Social Study Network (SSN: 쓴)    *프론트엔드와 첫 협업프로젝트

설명: 팀원들, 학교친구들과 공부시간을 공유하며 응원할 수 있는 소셜네트워크 사이트입니다.

제작: 2022.04.08~2022.04.14

시연영상: https://youtu.be/ZAMqhx5jCNU

깃허브: https://github.com/ymkwon3/ssn (프론트엔드) / https://github.com/moonhjang/miniproject_back (백엔드)

노션: https://www.notion.so/d556601ee2de4629a9a1947675f23dd6

와이어프레임

사용 기술

• Server: AWS EC2 (Ubuntu 18.04 LTS)
• Framework: Express (Node.js)
• Database: MongoDB (Mongoose)
• JWT (Json Web Token)
• Crypto-js
• CORS
• Front-end: React

핵심 기능

• 로그인/ 회원가입 페이지
  • 아이디 패쓰원드 입력 가능
  • 로그인 시, 토큰전달 (모든페이지에서 해당 토큰확인 기능)
  • 빈칸 및 아이디 형식(4자이상, 대소문자, 숫자, 특수문자(!@#"-_)) 확인 가능
  • 회원가입시 아이디/닉네임 중복검사
  • 비밀번호 재확인 일치 확인 가능
• 메인페이지
  • 해당 유저와 친구리스트 조회
  • 공부시간 시작/정지 버튼
  • 총 공부시간 조회가능
  • 친구 추가가능
  • 친구와 공부시간 순위 확인가능
  • 친구의 공부시간 및 접속 확인 가능
• 방명록 페이지
  • 등록된 친구 방명록에 코멘트 조회, 작성 가능
  • 방명록 주인과 방명록 작성자만 삭제 가능
  • 본인 방명록 페이지에서는 상태메세지 수정 가능

Trouble Shooting   

▶ Auth-Middleware에 대해 프론트 업무에 대한 이해부족했다.

→ 개인프로젝트 진행시, 로그인 실행시 로그인인증 확인API도 함께 확인되었다. 그때, 로컬스토리지에 유저 정보를 넣어두었다. 하지만 프론트에서 로그인인증 확인하는 방법이 따로 있기 때문에 굳이 필요없어 제외를 했다. 저장된 토큰으로 모든페이지의 로그인 인증확인하는 방법을 동일하여 문제없이 작동되었다. 

▶ 로컬에 있는 MongoDB를 사용하고자 했지만, 로컬DB의 내용을 확인하려고 하니 배포과정에서 오류가 발생하였다. 

→ 로컬DB를 사용하지 않고 MongoDB클라우드에 직접 연결하여 실행하였다. 

▶ _id를 commentid 로 사용하게 되면서, _id를 백엔드에서 object에서 string으로 객체 type을 변경해야하는 점에서 어려웠다.

→ Comment 스키마에서 _id를 commentid로 만들어 string으로 변경하여 전달하였다. 

개인회고

첫 프론트엔드와의 협력프로젝트였다. 프론트업무에 대한 지식이 부족했기에 표현방식과 이해하는 방식이 굉장히 달랐다. 프로젝트 중반부터는 서로의 업무를 이해하고 나니 생각보다 프로젝트가 문제없이 풀렸다. 

개인 프로젝트시에는 내 작업을 웹사이트에서 확인하는 것이 편했는데, 협력할 때는 확인할 수 없는 뷰가 없어서 불편했다. 썬더 클라이언트가 그 역할을 대신했지만, 회원가입이나 로그인 시 전달되는 정보를 직접작성해야하는 번거로웠지만 잘 적응 할 수 있었다. 특히, 모든페이지를 auth-middleware로 연결 후에는 토큰이 없기에 썬더 클라이언트를 사용할 수 없었다. (이후 알아보니, 헤더에 토큰을 넣어 확인해볼수 있다는 것을 알게되었다.) 

협력했던 프론트 분이 굉장히 잘하시던 분이라, 밴엔드로서 굉장히 도움도 많이 받았고 수월하게 프로젝트를 진행할 수 있었다. 프로젝트 진행시, 염려했던 CORS 이슈나 auth-middleware(인증미들웨어)에 대한 이슈는 거의 없었다. 배포 초반, 인증 미들웨어에 대한 약간의 이슈가 있었으나 콘솔찍으면서 전달하고 전달받는 데이터를 확인하니 큰 이슈없이 해결되었다.

굉장히 만족스러웠던 점은 모든 기능들이 문제없이 잘 작동했고, 모든 팀원들 또한 만족스럽게 끝낸 프로젝트라서 더 좋았다. 우리 팀원 모두 흥해라!

항해99 5주차에는 프론트엔드와 백엔드가 함께 미니프로젝트를 진행하게 되었다.

그전에도 CORS 모듈을 설치에 진행하는 것이 좋다라고만 들었는데, 

프론트 작업과 연결시 필요한 작업이기에 CORS를 자세히 알아보기로 했다.

CORS란?

CORS(Cross-Origin Resource Sharing), 교차 출처 리소스 공유라고 해석된다. 
CORS정책은 우리가 가져오는 리소스들이 안전한지 검사하는 관문이다. 

웹 개발을 하다보면 CORS 정책 위반으로 인해 에러가 발생한다. 콘솔에서 아래와 같은 메세지를 확인할수 있다.

CORS 관련 이슈는 모두 CORS 정책을 위반했기 때문에 발생한다.

위의 에러는 CORS를 허용해서 아무런 탈 없이 다른 출처 리소스를 공유해달라는 권고사항과 같은 것이다.

CORS라는 방어막 덕분에 우리가 이 곳 저 곳에서 가져오는 리소스가 안전하다는 최소한의 보장을 받을 수 있다.

출처 (Origin) 란?

서버의 위치를 의미하는 URL은 Protocol, Host, Port 까지를 의미한다. 

웹에는 SOP(Same Origin Policy) 와 CORS(Cross Origin Resource Sharing) 두가지 정책이 있다.

▶ SOP(동일 출처 정책) ◀

같은 출처에서만 리소스를 공유할 수 있다" 라는 규칙을 가진 정책

→ URL의 구성요소 중 Protocol, Host, Port 세가지 동일한지 확인한다.

→ 같은 Protocol, Host, Port을 사용한다면 요소는 다르더라도 같은 출처로 인정된다.

→ 리소스가 자신의 출처와 다를경우, 브라우저는 교차출처 요청을 실행한다. 

즉, Protocol, Host, Port 중 하나라도 일치하지 않으면 Cross Origin 이라고 한다. 

▷ 실무에서 참고하자면 ◁

프론트 서버와 백엔드 서버 연결시

프론트 서버 URL이  http://localhost:3000,

백엔드 서버 http://localhost:8080 일때

SOP 정책에 어긋나기때문에, 서버로부터 응답이 넘어올 때 

브라우저에서 CORS 정책 오류를 발생시킨다. 

▶ CORS (교차 출처 리소스 공유) ◀

추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 어플리케이션이 다른 출처의

선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에게  알려주는 체제이다. 

CORS 동작방식

1. 클라이언트에서  HTTP요청 헤더에 Origin을 담아 전달한다. 

2. 서버는 응답헤어에 Access-Control-Allow-Origin을 담아 클라이언트로 전달한다.

3. 클라이언트에서 자신이 보냈던 요청의 Origin과 서버가 보내준 Access-Control-Allow-Origin을 비교한다. 

자신이 보낸 Origin과 서버가 보내준 Access-Control-Allow-Origin을 비교하여 차단할지 말지 결정한다. 

만약 유효하지 않다면 그 응답을 사용하지 않고 버린다. 

(위의 경우 둘다 http://localhost:3000 이기 때문에 유효한 경우다.)

아래의 블로그를 참고하여 작성되었습니다.

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-CORS-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC-%ED%95%B4%EA%B2%B0-%EB%B0%A9%EB%B2%95-%F0%9F%91%8F

프로젝트 : 로그인/회원가입 페이지

설명 : 로그인, 회원가입, 게시글 코멘트 등록, 조회, 수정, 삭제 기능구현 연습을 위해 제작되었습니다. 

제작 : 2022.03.25 ~ 2022.03.31

시연영상: https://youtu.be/sNPd6aWwgQM

깃허브:  https://github.com/moonhjang/node_1

사용 기술

• Server: AWS EC2 (Ubuntu 18.04 LTS)
• Framework: Express, Mongoose(Node.js)
• Database: MongoDB
• front-end: HTML5, CSS3, Javascript, Jquery, bootstrap

핵심 기능

• 회원가입페이지
• 로그인 페이지 
• 로그인 검사
  • 조회페이지 제외, 로그인 한 경우만 볼수 있도록 하기
• 댓글
  • 로그인한 사용자만 댓글 추가/ 수정/ 삭제

Trouble Shooting

▶ 인증이 필요한 페이지와 인증미들웨어를 연결되어있지만, 안내 알람이 JS파일이 아닌 HTML파일의 알람을 띄우는 이슈가있었다. 

→ 인증 미들웨어.js와 router.js 이 제대로 연결되어 있지 않았다. 로그인시, 미들웨어와 연결된 로컬스토리지에 잘못된 인증키가 들어가게 되면서 인증 키를 제대로 전달해주지 못하면서 생겨난 이슈였다. 연결이 잘 되면서 알림이슈는 해결되었다. 

▶ 댓글 추가시, mongoDB의 subdocument이용방법으로 댓글을 추가하였다. 이와 같은 방법으로 조회를 하려고 했지만 예상치 못한 오류로 작동이 되지않았다.

→ 예상치 못한 오류를 잡기위해서 Try-Catch문을 이용하여 해결되었다.

+ 지난주 작업에서 아쉬웠던 비밀번호 암호화 처리 및, env 파일과 .gitignore을 사용하여 보안을 강화하였다.