일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- 동적계획법
- Brute Force
- graph
- DP
- 그래프
- BFS
- Greedy
- 힙
- DFS
- sort
- 코딩테스트
- DVWA
- Dynamic Programming
- string
- 정렬
- 알고리즘
- heap
- 탐욕법
- programmers
- binary search
- Queue
- 큐
- django
- 프로그래머스
- 문자열
- Code Refactoring
- 백준
- Algorithm
- 완전탐색
- 카카오 기출
- Today
- Total
생각과 고민이 담긴 코드
코드 리팩토링/ Rest api 설계#1 (문제 인식) 본문
현재 진행 중인 팀프로젝트에서는 제조원가를 예측하는 웹 플랫폼을 개발하고 있다.
기술 스택은 Django 프레임워크와 html, javascript를 사용하고 있다. 현재 웹페이지 화면은 총 16개 정도의 화면으로
이루어져 있으며 대부분의 화면들은 DB의 데이터들을 보여주는 grid 형식의 화면이다.
또한 장고의 FBV를 사용하여 화면마다 한개의 html 파일 랜더링 해주는 view함수를 배정해주고 있는데 문제는 화면마다 CRUD 기능이 필요하기 때문에 각 화면마다 최소 3개이상의 view 함수와 url 경로가 더 필요하게 되었다.
그 결과 다음과 같은 매우 비효율적인 구조가 되고 말았다.
위와 같이 화면마다 총 4개의 url을 맵핑하게 되었고 그에 따라 view함수도 4개씩 필요하게 되었다.
16개의 화면이니 코드는 점점 복잡해지게 되었고 url 구성 또한 동사가 들어가는 등 비표준적인 형태를 띄고 있었다.
또한 클라이언트 쪽에서도 ajax 방식으로 서버에 요청을 하는데 xhr 객체에 "POST"를 인자로 넣어 open하지만
실질적으로는 쿼리스트링을 통해 정보를 url에 다 넣어서 보내는 GET방식으로 요청을 보내는 비표준적인 형태를 띄고 있었다. 추가적으로 장고 템플릿 언어를 통해 클라이언트와 서버가 너무 밀접하게 묶여 있어 이 또한 분리 시킬 필요가 있었다.
따라서 전체적인 프로젝트의 완성도를 높히고 추후에 있을 모바일로의 확장을 위해서 REST api를 설계하기로 하고
현재 django 서버에서는 정적인 html파일들을 render해주는 역할만 진행하고
새로 api 서버를 만들어서 DB에 접근하여 동적인 컨텐츠 즉, 데이터를 다루는 CRUD 기능을 위임할 생각이다.
'Code review & Code refactoring' 카테고리의 다른 글
코드 리팩토링/ Rest api 설계#3 (Django CORS 정책 관련 설정) (0) | 2021.03.28 |
---|---|
코드 리팩토링/ Rest api 설계#2 (Django Rest Framework) (0) | 2021.03.12 |
팀원 코드리뷰#2 (1) | 2021.02.16 |
팀원 코드리뷰#1 (0) | 2021.02.05 |