플라이북 스크린 구조
스크린 구조
프론트, 백엔드가 나뉘어져 있음
- 프론트는 (보이는 스크린 영역을 뜻함)
- 백엔드는 (서버통신, 데이터베이스 등 보이지 않는 영역을 뜻함)
프론트
laravel + Vue.js
larascreen
독립
백엔드
laravel
api2 (flybook 서버코드)
앱 서버 + 스크린 서버
프론트
1. 기본 화면 구성
2. 백엔드에 필요한 데이터 수집
설문에 따른 추천책
이럴 땐 뭐 읽지
요즘 어때요?
백엔드
1. 결과를 제공하기 위한 서버코드
2. 프론트에서 받은 데이터를 바탕으로 결과 데이터를 제공
현황
- 추가 도서관 확정 시 진행 절차
- 도서관 전체 책 리스트를 데이터화하여 저장
- 스크린을 통해 받은 설문을 바탕으로 api2에 내장되어 있는 책 추천 알고리즘을 통해 추천책 리스트화
- 도서관 데이터베이스에서 책 있는지 유무를 확인하여 결과 출력
- 프론트에서 받은 데이터를 바탕으로 api2서버코드로 접속
- 프론트데이터 > api2 > library > 서버코드 > 프론트결과
- 앱과 스크린이 api2 서버코드를 함께 사용
문제
1. 스크린 갯수 확장은 가능 , 스크린 서버 코드 기능 개선 어려움
- laravel로 만들어진 서버코드를 직접 건드려야 함
2. 프론트 에러 발생시 해결 가능 , 서버 에러 발생시 해결 어려움
- laravel 서버 코드에 대한 숙련도 부족으로 인한 즉각 대응 어려움
3. 스크린에 사용되는 서버코드와 app 코드의 연관이 전혀 없음
진행방향 (단기)
1. 절차 (추가 도서관 확정 시)
1) 도서관 전체 책 리스트를 데이터화하여 저장
2) 스크린을 통해 받은 설문을 바탕으로 api2에 내장되어 있는 책 추천 알고리즘을 통해 추천책 리스트화
3) 도서관 데이터베이스에서 책 있는지 유무를 확인하여 결과 출력
2. 프론트에서 받은 데이터를 바탕으로 api2서버코드로 접속
- 프론트데이터 > api2 > library > 서버코드 > 프론트결과
- 플라이북 app과 스크린app이 api2 서버코드를 함께 사용
위 절차를 바탕으로
스크린 확장
작업 계속 진행
(단기)
진행방향 (장기)
1. 절차 (추가 도서관 확정 시)
1) 도서관 전체 책 리스트를 데이터화하여 저장
2) 스크린을 통해 받은 설문을 바탕으로 api2에 내장되어 있는 책 추천 알고리즘을 통해 추천책 리스트화
3) 도서관 데이터베이스에서 책 있는지 유무를 확인하여 결과 출력
2. 프론트에서 받은 데이터를 바탕으로 api2서버코드로 접속
- 프론트데이터 > api2 > library > 서버코드 > 프론트결과
- 플라이북 app과 스크린app이 api2 서버코드를 함께 사용
간소화 및 분리 작업
1. 불필요한 데이터베이스 제거 & 간소화
2. 스크린 서버 코드 분리
(장기)
1. 불필요한 데이터베이스 제거 & 간소화
도서관 데이터베이스 저장 및 관리 더 이상 안 할 예정
- 고객 설문을 바탕으로 각 분야별 책을 10권 추천 (혹은 그 이상)
(많지 않을 경우를 대비) (나이, 관심사, 상태)
- 추천된 책의 ISBN을 바탕으로 각 도서관 api에 접속해
도서 유무를 확인하여 제공
(열람실 위치, 청구기호 번호, 대출가능여부)
효과
1. api접속을 바탕으로 한 실시간 정보 제공 가능
2. 도서관의 도서 변경 또는 폐기와 같은 변화에 대응할 필요가 없음
3. 데이터베이스 관리 최소화 (비용 절감)
4. 데이터베이스 삽입하는 작업 삭제 (시간 단축)
2. 스크린 서버 코드 분리
스크린 전용 서버 코드 분리
효과
1. node.js 를 활용한 서버 코드 분리
- vue.js, node.js 모두 javascript로 관리 가능
- 코드언어의 일원화로 서버, 클라이언트 모두 관리 용이
2. 문제 분리 및 속도 개선 가능
- app과 스크린의 서버코드를 분리하여 에러 분기 가능
플라이북 스크린 구조
By Hae Jun Kim
