입소 직후부터 시작해 4일간 밤새워 진행한 프로젝트 Tarzan(타잔)을 드디어 완성하고 발표했다.
정말 힘들었지만 이 짧은 시간에 엄청나게 성장했다.
기능 구현과 배포까지 완료해서, 더 수정할 것도 없다. 3일만에 프로젝트 하나를 완성하였다.
간단한 트러블 슈팅들
1. git 오류
git을 처음 다뤄봤는데, 이와 같은 오류를 만날 수 있었다.
이럴 땐 pull을 먼저 진행한 후 push하면 된다.
2. git 파일 이름 변경
git mv 명령을 사용하지 않고 파일 이름을 변경하면 git에서 해당 파일을 delete된 것으로 인식하고 이름이 바뀐 파일을 새로 추가된 파일로 인식할 수 있다. 이렇게 되면 delete된걸로 인식한 파일은 커밋 추적도 불가할 수 있다.
따라서 git에서 파일 이름을 변경하려면 반드시 "git mv 파일명1 파일명2" 이런 식으로 git을 붙여 변경해야 한다.
3. JS, window.location.href
window.location.href를 boardList.html 이런 식으로만 호출해야 하는 줄 알고 데이터를 어떻게 받아올 지 고민했었다.
하지만 "http://localhost:33333/boardList" 이런 식으로 호출하면 /boardList api를 호출할 수 있었다.
4. JS 함수 이름
JS코드 작성 시 함수 이름을 submit()으로 했는데 알 수 없는 오류가 계속 출력되었다.
알고 보니 submit()은 내장 함수의 한 종류였기 때문에 충돌했던 것으로 보인다.
함수 이름을 submit2()로 변경하니 오류가 해결되었다.
5. house_list = db.article.find({'house':house,'name':name})
MongoDB에서 데이터를 뽑아내는 코드다. find를 사용하면 커서(cursor)라는 특별한 객체를 응답받는데, 이 객체는 리스트처럼 반복문에 넣어 사용이 가능하다. 하지만 분명 데이터를 받아오는데도 return할 때 값이 계속 비어있는 오류가 발생했다.
알고보니 cursor객체는 "1회용" 이었다. 한번 반복문을 돌리고 나면 그 객체는 비워져 버린다.
데이터를 잘 받아오는지 확인하기 위해 반복문으로 한번 print해보고 return 했는데, 그래서 값이 비워진 거였다.
6. db명 항상 확인하기
분명 db코드는 잘 작성했지만 아무리 해도 값을 가져오질 못해서 끙끙 앓았었는데, 그냥 db명을 잘못 입력한 거였다.
당연히 값이 가져와질리 없다.
항상 db명이든 변수든 함수든, 이름과 오타를 잘 확인하는 습관을 가지도록 하자.
7. 게시글 삭제 이슈
게시글을 삭제해야 하는데, 삭제 버튼이 하나밖에 없었다. 이래선 게시글을 구분할 고유값을 어떻게 가져와야 할 지 막막했다.
$('#updateDetail').attr('onclick', "modifyArticle('" + articleId + "')")
게시글을 조회하는 함수에 이 코드를 추가해 해결했다.
게시글에 포함된 articleId(게시글 고유 _id) 값을, 수정 버튼의 함수 호출 인자쪽에 넣어주어 해결할 수 있었다.
프로젝트를 진행하며 공부한 것들
JWT(Json Web Token)
- 서버에 과도한 세션 정보를 저장하게 되는 기존 방식을 해결하기 위해 도입된 "클라이언트 기반 인증 방식"
- 사용자가 로그인 요청을 하고 성공하면, 서버는 Access Token을 발급한다.
- 이후 사용자는 서버에게 요청을 전송할 때 Access Token을 포함하여 전송한다.
- 서버는 Access Token의 유효성을 검증한 후 응답을 보낸다.
JWT의 Access Token
- 사용자를 고유하게 식별할 수 있는 데이터를 포함하여 생성한다.
- 토큰은 "클라이언트"측에 저장된다.
- 서버는 토큰 자체를 가지고 있지는 않는다. 토큰을 검증하고 응답을 보낸다.
jinja2
- 파이썬에서 사용되는 SSR(Server Side Rendering) 템플릿 엔진. 서버에서 받아온 데이터를 효과적으로 출력하기 위한 중간 매체.
- html문서에 동적으로 데이터 값을 포함하게 한다.
- html문서에서 반복문, 조건문, 변수 등을 사용할 수 있게 한다.
- 스프링의 Thymeleaf와 같은 기능을 한다고 보면 된다.
Rendring(렌더링)
- 웹 페이지를 사용자가 볼 수 있는 형태로 변환하는 것.
- HTML과 CSS를, 또는 데이터까지 함께 사용자가 시각적으로 볼 수 있도록 만드는 것이다.
CSR(Client Side Rendering)과 SSR(Server Side Rendering)의 특징 및 차이점
CSR 특징
- 클라이언트 측에서 렌더링이 일어난다.
- 클라이언트가 서버로부터 HTML과 JS 코드를 받은 후, api호출 및 데이터를 전달받아 렌더링이 일어난다.
- 클라이언트 측에서 HTML, JS 코드를 받은 후 렌더링이 완료될 때까지 사용자는 아무것도 볼 수 없다.
- 초기 로드가 빠르지만 이후 제대로 렌더링 되기까지 시간이 걸릴 수 있다
SSR 특징
- 서버 측에서 렌더링이 일어난다.
- 정확히는 클라이언트 측에서 "즉시"렌더링할 수 있도록, 모든 준비를 끝마친 데이터를 전송한다.
- 클라이언트가 파일을 전달받으면 즉시 렌더링되고, 사용자는 바로 페이지를 볼 수 있다.
- 서버측에서 렌더링 준비를 끝마친 후 클라이언트로 전송하기 때문에, 초기 로드가 느릴 수 있다.
- SEO(Search Engine Optimization)에 유리할 수 있다. 검색 엔진에서 잘 색인화되는 경향이 있다. (CSR에 비해 잘 노출되고, 상위에 노출될 수 있다)
- SPA(Single Page Application)에서 불리할 수 있다. 서버에서 대량의 데이터를 한번에 렌더링해야하기 때문.
SPA(Single Page Application)
- 하나의 페이지로 구성된 웹
- 메뉴를 선택하면 헤더는 고정된 상태로 메인화면 혹은 클릭한 부분만 바뀜
- 즉 이론상 페이지는 하나지만, 실제 페이지 역할을 하는 다른 정보들을 초기에 한번에 로드한다.
- 일반적으로 CSR로 렌더링한다.
MPA(Multi Page Application)
- 전통적인 웹 페이지 구성 방식
- 이동할 때마다 새로운 HTML을 받아와서 렌더링한다.
- 일반적으로 SSR로 렌더링한다.
하지만 SPA -> CSR, MPA -> SSR은 일반적인 경우이지 항상 통용되는 것은 아니다.