E D R , A S I H C RSS

ZP Library


누구나 쉽게 배포하고 자신의 그룹에 맞춰서 쓸 수 있는 오픈소스 웹 앱을 만들자.
조영준이 추진 중. 멤버는 상시 모집중이며, 관심이 있을 경우 연락 주시기 바랍니다. 특히 다음과 같은 분들을 환영합니다.
  • 실제로 돌아가는 웹 앱을 만들어 보고 싶다!
  • 현대적인 프론트 웹 개발에 관심이 있다!
  • RESTful API 개발에 관심이 있다!
  • AWS를 써 보고 싶다!
  • 그냥 재밌어 보인다!
  • 조영준이 너무 좋다!

다만, 프로젝트 주도하고 있는 사람도 근성으로 배워가고 알아가며 진행 중이니 참고 바랍니다.

1. 이전 프로젝트

열파참/프로젝트에서 이미 한 번 시도를 했으나, 다음과 같은 이유로 갈아엎기로 결정.

1.1. 날뛰는 구조

딱 프레임 워크의 사용법만 익힌 후 설계나 추가적인 공부 없이 바로 코드를 작성 해서 구조가 괴랄해짐.

1.2. 잘못된 프레임웍 선정

Django와 함께 AngularJS를 이용했으나, 서버에서 도느냐 클라에서 도느냐 차이만 있을 뿐 둘 다 동일하게 웹에서의 MVC패턴을 지원하는 프레임웍. 역할이 겹치다 보니 둘 다 입지가 애매해졌다. 그리고 결정적으로, GAE(Google App Engine)은 일반적인 SQL을 사용할 수 없기 때문에 Django의 매우 큰 장점인 Model 부분을 써먹을 수가 없다!

2. 진행 내용

너무 지지부진해서 일단 만들면서 피드백을 받기로 결정. 이전처럼 구조가 괴랄해질 위험은 여전하나, 프레임워크들의 도움과 모듈화의 힘을 빌리는 것으로.
작업은 크게 두 부분으로 나뉜다. 모던 웹 클라이언트와 RESTful 백엔드 서버.

2.1. 클라이언트

https://skywave-dc.appspot.com
Polymer Starter Kit을 기반으로 하여 작업 진행 중.
  • Polymer: 웹 컴포넌트 프레임워크.
  • Google App Engine: PaaS... 이긴 한데 그냥 Static File 무료 호스팅 용도로 사용 중. Routing 및 앱 설정을 제외하고는 코드가 한 줄도 없는 상황.

2.2. 서버

초기에는 프로젝트 진행자가 구글에 취해 Google Cloud Platform만 바라봤으나 정신을 차리고 AWS과 비교해 본 결과 AWS가 더 낫다고 판단되어 AWS를 이용. 아직은 프로토타이핑중이라 프레임워크가 변경될 수 있으며, 아직 실제 클라이언트와 연결되지는 않음.
...은 옛 말이고 쓰다보니 생각보다 불편해서 GAE로 회귀. AWS는 서비스가 많긴 한데 아직 미숙해서 그런지 연결도 잘 못 하겠고 결정적으로 무료티어가 끝남. 현재 서버 구성은 다음과 같음:

3. 작업 일지

차근차근 정리하면서 쓰자니 손이 안 가서 그날 그날 작업한 내용을 기록.

3.1. 3월 21일

4. 설계

4.1. 프레임 워크 및 API 후보

  • Google App Engine - 줄여서 GAE. PaaS. 무료 제공 양이 상당한 편이라 사용.
  • Google Datastore - NoSQL DB. 무료도 무료지만 GAE와 궁합이 좋음.
  • Google Endpoints - RESTful 백엔드 서비스. GAE위에서 돈다면 완전무료.
  • AngularJS - 프론트엔드 웹 앱 프레임워크. Single Page Website를 만드는 것을 목적. Polymer로 대체할 수도 있음. AngularJS 자체가 좀 장황하다는 느낌이 있어서 Polymer 쪽으로 기우는 중.
  • Flask - 작업의 대부분이 AngularJS로 넘어갈 수 있기 때문에 훨신 가볍고 단순한 webapp2로 대체할 수도 있음.

  • Google Book API. 도서 정보 추출. 영어.
  • Daum Book API. 도서 정보 추출. 한글.

이 외에도 GAE에서 제공하는 이런 저런 서비스 사용 예정. 뭔가 구글판인 것 같지만 넘어가자.


4.2. 기능 명세

4.2.1. 도서 자동 추가

관리자에게 ISBN들을 입력 받고, 해당되는 ISBN의 책들을 도서 관련 API를 통해 검색한 후 자동으로 DB에 저장. 이 때, API Key값들을 환경 변수로 추가하여야 함.
사용자가 ISBN을 통해 특정한 책을 접근하려고 할 때 해당 책이 없으면 관리자에게 도서 추가를 요청할 수 있음. 물론 관리자는 승인/거절 선택 가능.
또한, 책 설명 부분에서 명사들만 추출하여 명사 목록을 추출한 다음, 원래 단어와 해당 단어를 지역에 맞게 자동 번역한 단어를 키워드로 자동 등록.

4.2.2. 로케일

누구나 쉽게 쓸 수 있다는 것은 국경을 가리지 않고를 의미...하지만 일단 국경은 둘째 치고 String 값들을 따로 빼는 것만으로도 관리가 용이해 지기 때문에 충분히 필요한 작업. json 형식의 locale 파일들을 ajax로 불러와서 사용자가 선택한 언어를 화면에 뿌려주자.

4.2.3. 환경 변수

단순히 서비스의 이름부터 시작해서 도서 검색에 필요한 API Key 등 일부 값들은 서비스 제공자가 입력하여야 한다. 이에 따라 생각되는 방법은 다음과 같음:
  1. environment variable: 말 그대로 시스템 환경 변수를 이용. 근데 GAE에서 제공 안 하는 것 같음. 더 찾아봐야 함.
  2. datastore를 통한 값 관리: 환경 변수를 이용할 때 마다 db에 쿼리를 날리기 때문에 성능과 할당량에 문제가 생김. 하지만 이는 memcache로 최소화 시킬 수 있을 것.
  3. json을 이용한 관리. 문제는 gae에서는 파일 읽기는 되나 쓰기가 되지 않기 때문에 웹 페이지상에서 수정을 하는 것은 불가능하고 사용자가 직접 json 파일을 수정해야 함.

4.2.4. 검색

제목 / 저자 / 출판사 / 전체 (앞의 3개 + 키워드)를 통한 검색을 할 수 있어야 함. 키워드의 경우 책 설명에서 추출하는 방법과, 사용자로부터 키워드를 추가하는 방법을 생각할 수 있음. Datastore는 full text matching이 되지 않기 때문에 Search API를 사용해야 하나, Tag를 Key로 가지고, 해당되는 ISBN들을 Value로 갖는 DataStore를 만든다면 Search API를 쓰지 않아도 될 듯.

4.2.5. 실시간 검색

Data Structure라는 책을 검색한다고 할 때, d만 입력 하더라도 해당 알파벳으로 시작하는 책 이름의 목록이 출력되는 기능. 위에서 언급했듯이 Full Text Matching이 되지 않기 때문에 첫 1~2글자를 기준으로 해싱을 한 다음, 사용자가 1~2글자를 입력 했을 때 JSON으로 해당 글자로 시작하는 책 제목의 목록을 보내준 다음 client에서 처리를 하는 방법을 예상 중.

4.2.6. 회원

비밀번호를 잘 저장할 자신이 없기 때문에 'Sign Up with~' 기능을 이용해서만 계정을 관리할 예정.
GAE에서 google 계정을 통한 인증을 지원 하나, 이전 프로젝트에서 google 계정을 사용하지 않는 사용자에 대한 이슈가 있었기 때문에 twiiter, facebook, github를 OAuth를 이용해 인증하는 방법을 추가 하는 것이 좋을 것.
가입을 한 후 인증의 방법은 다음을 지원할 예정:
  • 누구나 사용 가능
  • 지정된 도메인의 이메일로 가입할 경우 자동 인증
  • 관리자가 지정된 코드를 입력할 경우 자등으로 인증
  • 수동으로 인증

등급은 다음과 같이 구분하며, 항상 윗 등급은 아래 등급의 기능들을 포함한다. 등급에 따른 기능은 다음과 같다:
  • 최고관리자: 다른 사용자들을 관리자로 변경 가능. 환경 변수들을 보고 수정할 수 있음.
  • 관리자: 책을 추가/수정/삭제를 할 수 있으며, 다른 사용자들을 승인/미승인 회원으로 변경 가능.
  • 승인: 책을 대여할 수 있음. 책 추가 요청을 할 수 있음.
  • 미승인: 검색을 할 수 있음. 책 목록과 상세 정보를 볼 수 있음.

4.3. DB

4.3.1.

ZP에서는 기증자 정보가 필요하나, 이는 범용적이지 않음. 따라서 memo라는 항목을 통해서 기타 사항들을 관리자가 추가할 수 있도록 할 예정.

4.3.2. 태그

  • 태그
  • ISBN13

4.3.3. 사용자

  • Email
  • User ID Number
  • 이름
  • 등급 (최고관리자 / 관리자 / 사용자 / 미승인)

4.3.4. 대여

  • ISBN13
  • User ID Number
  • 대여일 / 반납일

반납일이 null일 경우 반납을 하지 않은 것.

5. 댓글

  • 보고 조언좀 해 주세요 굽신... -조영준
  • 사용자를 구분하는 것보다 권한을 구분하는 것을 추천. 사용자는 별개로 있는 것이고 사용자에게 권한이 주어지도록 하는 것이 더욱 유연할듯. 스펙에는 윗등급이 아래 등급의 권한을 다 가진다고 되어 있지만, 그렇지 않을 경우도 종종 생김. (ex. 사용자 삭제를 최고 관리자 권한으로 하고 사용자가 자기 자신을 삭제 할수있다고 하면, 중간에 낀 관리자는 사용자 삭제 권한이 없는데 일반 사용자는 제한되긴 하지만 삭제 권한을 가짐) - bluemir
Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2016-03-21 14:49:30
Processing time 0.0278 sec