최근 약 한 달 동안 아래 두 강의를 들었다.
- 네이버 부스트 코스 백엔드 편
- 백기선님의 스프링 부트
아무래도 따라하고 기록만 하다보니 뭔가 완전히 체득이 안 된 느낌이 들어, CRUD 게시판 이라도 하나 만들어야겠다는 생각이 들었다. 그런데 또 게시판만 만들자고 하니, 좀 재미가 없을거 같아 간단한 홈페이지를 만들어보게 되었다.
개발 기간은 대략 일주일.
그동안 배운거 복습한다는 느낌으로 만들었고, 만들어가며 있었던 과정과 작은 이슈들을 틈틈히 메모하여 여기에 기록한다.
결과물
스프링 부트 + Mustache + MySQL 로 만든 그냥 간단한 웹 페이지다.
아래는 홈페이지 일부 모습.
코드랑 Readme 는 깃허브에 올려놨다.
과정
1. 프론트 페이지 만들기
Pure JS + jQuery
가장 먼저한 건 프론트 페이지를 만드는 일이었다.
특히, 나처럼 백엔드 공부하는 사람들은 CRUD 를 실습하고 싶은 데 프론트 템플릿이 없는 경우가 많다.
프론트 페이지 짜자고 하니 또 한 세월이니 여간 귀찮은데, 아무튼 나와 같은 이런 분들이 내 프론트 페이지를 사용할 수 있게끔 짤 생각이었다. 즉, Pures JS 와 기껏해야 jQuery 정도 가지고만 프론트 페이지를 만들었다.*
Vue.js 나 npm 이용해서 써드파티 라이브러리들을 추가할 수도 있겠지만, 그럴려면 노드도 깔아야하고... 아무튼 프론트 엔드 공부가 필요한 이런 것들은 최소화시키고 싶었다.
걸린 시간은 대략 3일. 한 2년 전에 만들어 놓았던 페이지 가지고 하느라 비교적 빠르게 만들 수 있었다.
Flex & Grid css
부트스트랩 보통 많이 쓰는데, 이번 경우에 나는 안썼다.
모르겠다. 오랜만에 프론트 css 감을 좀 잡고싶어서 그랬는지, 최대한 Vanila 하게 만들고 싶었는지, 최대한 내 맘대로 밑바닥부터 커스터마이징 하고싶었나 보다.
부트스트랩 대신 비교적 최근에 css 3 에 추가된 Flex 와 Grid 를 활용했다.
이 둘은 css 가 얼마나 진화하고 있는지를 느끼게 해줬다.
과거에 이래저래 일종의 요령? 을 가지고 디자인하는게 많았다면, 이 둘은 그런걸 말끔히 처리해준다.
다음 링크가 많은 도움이 되었다.
관련 이슈들은 다음과 같은 것들이 있었다.
1fr 3fr
- >1fr minmax(0, 3fr)
- ajax 내 에서 리턴하면 안됨
- local date time
tui Editor
웹에서 사용자가 UI 를 통해 글을 쓰려면 위지윅 에디터 필요하다.
보통 제일 유명한 CK Editor, 이전에 Django 쓸 때 써봤던 Summernote 등 선택지는 여러 개 있었다.
아래 링크에서 무료 위지윅 에디터가 뭐가 있는지 볼 수 있었다.
나는 tui Editor 를 선택했다.
NHN 에서 만든 오픈소스로 커뮤니티도 활발하고, 도큐먼트도 잘 되어있는 듯 했다.
사용법도 아주 간단했다.
하지만 jQuery 는 아무래도 deprecated 되는 추세라 그런지 jQuery 관련 도큐먼트도 비교적 적었다.
cdn 을 이용한 적용 방법이 생각보다 순조롭게 잘 되지는 않았다. 결국 cdn 을 포기하고 로컬로 소스를 받아 사용했더니 말끔히 해결 되었다.
Base64 encoding
글쓰는 페이지에 해당 포스팅의 커버 이미지를 업로드하면, 동적으로 커버 부분에 즉각 렌더링해주는 개발 부분이 있었다. 문제는 파일 업로드한걸 브라우저가 어떻게 바로 렌더링해낼 것이냐 였다. 보통 이미지를 서버에 업로드한 뒤, js 가 이 파일의 url 경로를 가져와서 그려내는 식으로 알고 있었는데 지금은 서버가 없으니까...
그래서 찾아보던 중에, base64 encoding 이란게 있단걸 알게됐다.
그냥 바이너리 파일을 문자열 형태로 인코딩 하는 방법이다. 물론 압축의 느낌은 아니고 오히려 파일의 크기는 더 커진다. 다만, 별도의 파일 저장이 필요 없으며, 그냥 인코딩된 문자열을 브라우저가 바로 인식하여 렌더링 해준다는 것.
즉, 파일 크기 증가 때문에, 로딩 속도는 떨어지지만 문자열로 저장되기 때문에 별도의 로직없이 더 없이 편한 방법이었다.
심지어 jQuery 에 라이브러리가 이미 구축되어 있어 너무 편함.
tuiEditor 에서 사진 업로드는 어떻게 하나 보니까, 여기서도 그냥 base64 encoding 을 쓰더라.
물론 나중에 성능 최적화 문제에서 좀 걸릴 수 있겠지만은, 빠르게 만드는 거니 만큼 그대로 썼다.
로고
로고도 홈페이지를 이쁘게 하는데 한 몫한다.
여기저기 무료라고 써있는데가 많은데, 만드는 것만 무료고 다운받는건 유료인 경우가 많았다 ㅋㅋㅋㅋ
아래 웹 페이지가 제일 깔끔하고 심플한 로고만드는데 좋았다.
다운로드도 무료다.
2. 백엔드 서버 만들기
스프링 부트
음 그냥 바로 스프링부트 프로젝트로 시작했다.
스프링 버전은 현재 기준 제일 최신인 2.2.4 Release.
빌드 도구는 maven 4.
IDE 는 IntelliJ Idea Ultimate.
템플릿 엔진
템플릿 엔진으로 뭘 쓸까 고민했다.
일단 스프링 부트 공식 지원이 Thymeleaf 라 이걸 써볼까 했다.
그런데 뭔가 되게 불편했다. 뭐 익숙치 않은거니 당연한 거기도 한데, 아무튼 그냥 느낌이 잘 모르겠다 였다.
찾아보니 나와 비슷하게 느끼는 사람들이 꽤 있다는 걸 알게됐다.
그래서 굳이 이거 안써야겠다 해서 선택한게 mustache 였다.
Thymeleaf 와 다르게 java 외 다른 언어들에서도 많이 쓰이는 템플릿 엔진이고,
view 는 딱 view 의 기능만 할수있도록 logic-less 한 설계도 아주 맘에 들었다.
또, 나는 이전에 사용 경험이 있는 python 의 jinja2 템플릿 엔진이 익숙한데, 이와 그나마 유사했다.
Thymeleaf 바로 버리고, mustache 로 갈아탔다.
하면서 관련 렌더링이 가끔 안되는 이슈는 아래 링크를 참조했다.
프로젝트 구조
스프링 부트 프로젝트 구조는 내가 알기로 2가지가 있다.
- Controller, Service, DomainDto 으로 나누어 각 클래스를 담는 구조
- Domain 으로 나누어 클래스를 Controller, Service, Dto 를 담는 구조
이에 대한 설명은 아래에 잘 나와있다.
어떤 구조를 따를까 하다가, 난 후자를 따라가기로 했다.
이유는 별거 없고 난 그냥 이게 더 보기 편할 것 같았다.
네이밍 컨벤션
파일, 클래스, 메쏘드, URL 메쏘드 지을 때마다 잘 짓고 싶었다.
Java, Javascript 에서 혹은 그 프레임워크에서의 네이밍 컨벤션을 알아야했다.
뭐 한번 알아두면 그 뒤로 크게 신경쓰지는 않는데,
아무래도 처음이다 보니, 뭐 이름 짓는거 하나 할 때마다 컨벤션 먼저 찾아봐야만 했다.
URL 설계
글 에디터 페이지에 대한 URL 설계 중 다음 중 어떤게 맞을까?
post/edit
Post-edit
Edit-post
Restful API 설계 관련 문서도 조금 찾아봤지만... 일단 난 프론트 - 서버를 분리하지 않고 템플릿 엔진을 사용하니까 내 Controller 는 일단 Restful 자격에 못낀다.
그래도 최대한 비슷하게 만들려고 했는데... 노력하긴 했으나 갈수록 드는 생각은, 아 무조건 프론트랑 서버 분리하고 싶다는 생각이었다.
찾아봐도 뚜렷한 정답이 없어서, 일단은 그냥 내 느낌이 맞다는 생각대로 했다.
테스트코드
뭔가 하나를 완성했으면 테스트 코드를 만들어봐야 한다.
어차피 배운거 복습용이니까, 뭔가 뚜렷한 의미가 있진 않더라도 이런 프로세스를 몸에 배야겠다는 생각이었다.
junit4 , assertThat 에 대해서는 다음 사이트를 참고했다.
git..
IntelliJ 에서 git 쓰는게 좀 어색했다.
왜 자꾸 origin 이랑 conflict 떠서 rebase 나 merge 하라는 거지?
난 계속 push 만 넣고 있고 remote 는 내 로컬 하나 뿐인데....
CLI 가 편하긴 했지만, 그래도 최대한 IntelliJ git 을 써보려고 했다.
JPA
JPA 지식은 짧지만, 일단 아는거 + 필요할 때마다 일부 검색 으로만 해결했다.
물론 이게 최선인지는 모르겠고, 일단은 돌아가게끔만 해놓은 정도랄까.
@CreationTimestamp
/@LocalDateTime
- base64Image
LONGBLOB
자료형 사용- 하지만 성능 이슈가 있음.
JPA 는 진짜 나중에 따로 관련 강의를 들어야겠다는 생각이 마구마구 들었다.
배우고 제대로 짜야지...
서버 처리 vs 클라이언트 처리
렌더링 하기 전에 DB 데이터를 일부 손봐야 할 때, 이를 클라이언트에서 처리하는게 맞는지 서버에서 처리하는게 맞는지 잘 모르겠었다. 다 장단점이 있는 거라... 지금 나에겐 뭐가 적절한지 오픈 카톡방에다가 물어보기도 했다.
- decription 부분을 어떻게 처리할까
- DB 필드를 새로 만들까
- 내용 짧은경우 중복될 수 있음.
- 그래도 시간 코스트가 제일 적게 든다고 생각.
- 아니면 기존 필드를 서버에서 잘라서 보내줄까
- 근데 이러면 html 파싱 작업 필요함. 코스트가...
- 아니면 전체를 보내주고 클라이언트에서 자를까
- 이러면 통신 오버헤드가 너무 큼.
- DB 필드를 새로 만들까
- 날짜 포매팅 처리는 어떻게 할까
- 리스폰스 객체를 따로 만들까?
- 객체가 너무 많아지는거 아니냐...
- 클라이언트에서 처리?
- 클라이언트는 단순히 문자열만 받는건데....
- 리스폰스 객체를 따로 만들까?
뭐 아무튼 결과적으로 선택지 중 하나 선택해서 빠르게 개발했다.
성능 고민해봤자 지금 잘 모르고, 일단은 구현한 뒤 나중에 리팩토링하자는 생각으로 가게 되었다.
3. 추후 해야할 것들
깃허브 readme
에도 적어놨지만, 여기다가도 한번 더 적는다.
UX / 뷰 디테일
- 더 이상 표시할 아이템이 없을 경우, 목록 더보기 버튼 사라지게 하기
- 각 필드에 따른 아이템 정렬 작업
기능
- Project, Article 모델에 published 및 날짜 관련 필드 추가/수정
- Response 객체
- Security 적용해서 글 추가, 수정, 삭제 기능은 Admin 에만 포함시키기
성능
- JS 임포트 해오는 부분 로드 속도 최적화
- 이미지 DB 저장 관련 용량 최적화
테스트
- CRUD 관련 테스트 코드 구현
배포
- SQL scheme 정의 및 실행 시 샘플 아이템 자동 삽입.
- AWS 로 데모 페이지 배포
그 다음 버전
- RESTful 한 페이지를 위한 클라이언트 / 서버 코드 분리
- Admin 페이지 만들기
- 도커로 패키징
후기
맨 처음 개발 시작할 때 목표는, 프로젝트를 도커로 만들어서 사용하고 싶은 사람은 그냥 도커 이미지만 다운받고 run 시키면 바로 서비스가 동작가능 하도록 만들고 싶었다.
근데 일주일만에 이걸 하기에는 좀 무리였고, 지금은 데이터베이스를 먼저 띄워야 하고, 스프링 부트 설정을 좀 해야 동작가능한 프로젝트 형태가 되어버렸다.
결론적으로, 아무튼 누가 사용하기에는 좀 그렇고 그냥 개인 연습용 프로젝트란 느낌임.
더 욕심부리면, cms 같은 일종의 어드민 페이지도 만들어 보고 싶다.
나중에... 좀 더 코드를 잘 짜는법을 배우면 해야겠다.
'프로젝트들' 카테고리의 다른 글
[DND 4기] 서버 개발 회고 1 - 서비스 소개 및 개요 (5) | 2021.03.06 |
---|---|
데이터로 내 티스토리 블로그 EDA 하기 (4) | 2020.03.03 |
[All about 따릉이 EDA, 번외] 데이터에 없는 따릉이 대여소의 지역구 데이터 얻기 (4) | 2019.07.19 |
[All about 따릉이 EDA, 6편] 대여소별 따릉이 대여건수 예측 (2) | 2019.07.19 |
[All about 따릉이 EDA, 5편] 마포구, 따릉이는 얼마나 어떻게 이용되고 있을까? (6) | 2019.07.19 |