Airtravel
여행을 사진과 함께 기록하고 공유하는 웹 어플리케이션
프로젝트 선정 이유
SNS에 많은 정보들이 올라오는 만큼 sns는 이제 하나의 검색도구가 되었다고 무방하다. 우리는 여행에 특화된, 여행에 진심인 사람들이 새로운 여행 검색도구를 만들어가면 좋겠다는 생각으로 여행을 위한 SNS를 만들어보기로했다.
주요 기능
- 메인화면에는 어플에 등록된 모든 사진들을 볼 수 있음
- 작성된 글을 대륙별로 필터링해서 찾아볼 수 있음
- 로그인을 하면 mytour 페이지에서 내가 작성한 글을 볼 수 있음
- mytour 페이지에서 새 글을 작성 할 수 있음
- 게시한 글을 수정, 삭제 할 수 있음
- 업로드된 글에 좋아요 누를 수 있음
- 로그인 정보에 따라 좋아요 표시된 사진을 볼 수 있음
사용 기술
- front) html, css, javascript, jquery, jinja2
- back) python, flask, jwt
- DB) mongoDB
Git Repository
https://github.com/kimdovi-dev/Airtravel999
결과물
https://www.youtube.com/watch?v=J5XoAHBKuZI
개발 파트 분배 및 일정
21.11.01 - 21.11.07
- 프론트엔드: 김도은, 신경준
- 백엔드: 피수연, 전상혁
개발 중 마주한 문제점들
- 만들기 전 설계를 꼼꼼하게 하지 않아 만드는 도중에 다시 회의를 하고 설계를 해야했음.
- 마감날을 제대로 알지 못해서 제출날에 제출을 하지 못함. (아주 큰 문제점)
- 기능 욕심으로 인한 시간 부족.
- 우선순위 미설정으로 인한 개발지연. ( 작은 기능 버그보다 큰 기능 구현에 초점을 맞추고 진행했어야함. )
- Git 사용에 있어서 초기에 미숙했고, 한 파일을 동시에 수정해서 merge conflict가 자주 일어나서 git merge에 시간을 너무 많이 씀.
- 서버사이드 렌더링에서 어려움을 느낌.
- 각 html별로 사용되는 공통 컴포넌트에서 수정 사항이 생길 때마다 각 html 파일에서 반영 시켜줘야 하는데 나중엔 관리가 안되서 힘듦.
- 결국엔 렌더링을 jinja에서 해야 하다보니, front-end에서 작업을 해도 나중에는 back-end로 코드를 옮겨셔 jinja로 반영시켜야 했는데... 수정 사항이 생길 때마다 이 작업이 진행 되어야 해서 나중엔 관리가 힘들었다.
개발 중 마주한 나의 문제점들✏
- 기획은 너무 중요하다. 계획에 없던 기능들이 우리의 입맛에 따라 계속 추가하고 빼고의 과정을 번복하면서 코드 관리가 안되기 시작했고 실력이 부족한 상태에서 코드 재사용 가이드를 잡았던 것이 오히려 독이 되었던 것 같다ㅜㅜ 🌱기획에 없는 기능을 추가해도 문제 없도록 코드를 짤 수 있게 컴포넌트화 하는 것을... 더 연습 해야겠다.
- 컴포넌트화, 더 짧은 코드에 집중하다보니, 다른 사람이 보기엔 🌱다소 난해한 코드를 작성해서 시간이 지체된 것 같다ㅠㅠ 코드가 좀 더 길어지더라도, 팀원이 알아볼 수 있는 코드를 작성하는 것이 훨씬 효율적이라는 것을 뼈저리게 체험.
- 🌱직관적인 변수명, 클래스명을 설정하는 방법은 없을까? 개인적으로 클래스 명도 정말 잘 짓고 싶었는데 그게 잘 안된 것 같아서 속상했다...
프로젝트에서 중요한 개념
서버사이드 렌더링(Server Side Rendering)
렌더링이란 데이터를 요청을 해서 서버로 부터 받은 내용을 브라우저 화면에 표시하는 것을 말한다.
서버 사이드 렌더링(SSR)이란 서버에서 필요한 데이터를 모두 가져와서 Html파일을 만들고 Html파일과 함께 동적으로 제어할수 있는 코드(자바스크립트 코드)를 브라우저에게 전달하는 것을 말한다. 서버는 요청받은 HTML파일을 전송하고 브라우저는 받은 HTML을 보여주는 하는 방식으로 브라우저는 페이지를 이동할 때마다 서버에게 새로운 페이지를 요청한다. 이렇게 하면 페이지 요청마다 페이지 새로고침이 일어난다.
장점
- 모든 컨텐츠가 html에 담겨 있기 때문에 검색엔진 최적화(SEO) 가능
- 성능 개선, 첫 렌더링된 Html을 전달하기 때문에 초기 로딩 속도가 빠르다.
단점
- 좋지않은 User Experience. 요청이 일어날때마다 페이지가 리로드 되는 Blinking issue, 사용자가 클릭하게되면 전체적인 웹사이트를 다시 서버에서 받아와야 함은 static sites과 같다.
- 서버에 과부하가 걸리기 쉽다
- 자바스크립트 파일을 받아와야 interection이 가능하다. 사용자가 브라우저를 볼 수 있는 시간과 실제로 상호작용 할 수 있는 시간의 공백기가 꽤 길다.
JWT
JWT란 JSON Web Token의 약자로 클라이언트와 서버가 JSON 파일 안에 필요한 데이터를 주고 Token형태로 Authentication 정보를 주고 받을 수 있다.
JWT는 header, payload, signature로 구성되어 있다.
Header: alg(사용하는 알고리즘), typ(타입)으로 구성
타입 'JWT'는 고정값이고 알고리즘은 signature를 만드는데 사용 될 알고리즘이 지정된다. HS256 등 여러 암호화 방식 중 하나를 지정할 수 있다. JWT를 어떻게 검증하는가에 대한 내용을 담고 있다.
Payload: 주고받을 수 있는 데이터 -> 인코딩, 보안처리 돼있음
signature: 인코딩하기 위해 사용하는 서버의 비밀키(secret)과 함께 인코딩. header와 payload를 합친 문자열을 서명한 값이다. 서명은 헤더의 alg에 정의된 알고리즘과 비밀 키를 이용해 성성하고 Base64 URL-Safe로 인코딩한다.
1) 사용자가 로그인을 하고 유효한 사용자라면 사용자의 id와 원하는 정보를 묶어 JWT를 만듬
2) 만들어진 JWT를 사용자게에 보내줌
3) Client에서 요청할때 header에 JWT를 포함해서 서버에 전달함.
4) Server에서는 Client요청에 받은 JWT를 유효한지, 만료되었는지, 사용자의 정보가 정확한지 유효성을 검사함.
5) 요청에 맞는 데이터를 Client에게 보내줌.
장점
- 서버측 부하를 낮출 수 있고 능률적인 접근 권한 관리를 할 수 있다.
- 서버를 확장하거나 마이크로 서버나 분산형 시스템으로 만들어도 서로 서버간의 네트워크 요청을 통해서 사용자의 검증을 하지않아도 JWT를 만들고 해독할 수 있는 secret 키만 가지고 있으면됨
단점
- 서버에는 토큰을 보낸 사용자에 대한 정보가 없기 때문에 토큰이 탈취당한 경우 무효화 할 방법이 없다.
- Client와 Server간에 JWT자체를 주고 받기 때문에 보안에 주의 해야함
API
API(Application Programming Interface)란 서버와 클라이언트사이에서 요청과 응답을 주고받기 위한 체계이다.
가장 기본적인 WEB APIs 디자인 -> CRUD로 디자인
CRUD
- HTTP Method을 통해 구현
- Create -> POST
- Read -> GET
- Update -> PUT
- Delete -> DELETE
프로젝트를 마치고 개인적인 회고...✨
📌왜 프레임워크와 SCSS가 생겨났는지 알 것같다...ㅋㅋ html과 css와 script의 조합으로 프로젝트를 진행하는 것이 얼마나 고단하고 비효율적인지를 느꼈다ㅎㅎ
📌Git에 대한 이해도의 중요성....!!!!!! 개인적으론 개발 능력도 중요하지만 git 활용 능력을 기르는 것도 너무 중요하다는 것을 배웠다.
📌어쨌든 기한은 정말 중요하다. 이게 만약 실무였다면 우리 팀은 고객과의 약속을 어긴 셈이 된다. 정해진 기한 내에 진행될 수 있는 기능인지, 우리가 이 기능을 얼마 만에 구현할 수 있는지를 객관적으로 바라볼 수 있는 눈을 기르는 것도 필요한 것 같다.
📌전반적으로 내가 그동안 부족하다 생각했던 것들이 여실히 드러났던 프로젝트 였지만, 그럼에도 불구하고! front-end 개발에 대한 애착이 더 커질 수 있었던 것 같다. 다음엔 더 잘해야지.