flurry.olaf.kr 개발 후기

Screen Shot 2017-10-22 at 3.27.07 PM.png

1. Bootstrap4 쓴 이유

오랜 알파를 끝내고 베타가 나왔다. 알파에서 베타를 넘어갈 때는 많은 부분에서 API가 변경되지만, 베타부터는 버그잡고 RC로 넘어가는 경우가 많기도 하거니와 jQuery 없이 구현하고 싶은 욕심 때문이 가장 컸다.  bootstrap-vue가 bootstrap을 버전 4부터 지원하기 때문에 4를 사용. 내가 사용하는 부분에서는 일단 모두 안정적이었음.

2. 배포 스크립트

겸사겸사 jenkins를 공부 겸 써볼까 했었는데, 일단 당장 빨리쓰는 것이 급해서 무려 “쉘 스크립트”로 배포 스크립트를 작성했다. ㅎㅅㅎ… 일단, /var/www/ 에 폴더를 하나 만들어서 그곳에 webpack build output을 뱉어내는 식으로 짰더니, minify sourcemap까지 같이 들어가면서 얘기가 귀찮아졌다.


/mnt/host는 docker container에 마운트된 git 폴더 host 루트이고, /mnt/www/busun은 host의 /var/www 밑에 생성한 nginx에서 서빙될 루트이다. 일단 빌드해보고, 빌드가 성공했으면 if 절을 실행해서 원래 있던 폴더를 백업해놓고 빌드된 결과물들을 옮기고, sourcemap들을 지정된 곳으로 따로 옮기는 식으로 작업했다.

조금 더 빡세게 nginx 단을 조정해가면서 완전히 끊김 없는 배포를 할 수도 있었겠지만 호스트에 node 깔기 너무 싫어서 (?) 적당히 이 정도 선에서 타협ㅎ.. 내가 테스트 코드를 짠 것도 아니고 잘 짜지도 못하고 짤 생각도 없으니 ~_~

3. 국제화

국제화는 항목이 너무 길어져서 별도의 글로 분리했다.

Vue.js에는 vue-i18n과 vuex-i18n두 가지 국제화 라이브러리가 있었는데, 물론 Front-end의 비지니스 로직에서도 번역이 필요한 경우가 있다는 것에 동의 하지만, 그게 라이브러리 수준에서 타게팅을 그 쪽에다 맞출 필요까지 있었나 싶고, vue-i18n이 더 개발이 활발한 것 같아서 이 쪽으로 결정. 번역 텍스트를 정리한 파일은 바로 이것.

4. localForage

큰 차이가 날 정도로 큰 데이터를 다루진 않지만, 그래도 대부분의 로직을 localForage로 짜는 것을 선호한다. 유일한 단점을 꼽자면, 국제화에서 브라우저에 저장한 값을 불러올 때 async하게 짜려면 골머리가 터진다는 것. 이 부분은 그냥 window.localStorage 로 대체하고, 이외의 모든 자료는 localForage로 사용했다. 사랑해요 mozilla!

5. scoped scss를 선호하지 않았던 이유

사실 쓰지 않을 이유는 없다. 내 vue template에 대한 이해가 부족헀다. style element를 여러 개 만들어도 된다는 사실을 몰랐던 것에서 기인한 실수였다.

bootstrap4의 css를 조금씩 손 보고 싶은 부분이 있었다. 이런 부분들을 scoped된 scss에서 적용하면 “당연히” 내 scss 코드는 bootstrap component에 적용되지 않는다. 이런 귀차니즘을 없애고자 모든 모듈의 scss를 scoped되지 않은 것으로 작성했는데, 오히려 이 부분을 scoped, unscoped로 나눠서 작성했으면 어떤 코드가 bootstrap과 dependency가 걸려있는 부분인지 더 명확하게 되는,  Separation of concerns을 더 잘 만족하는 스타일로 짤 수 있었겠다는 아쉬움이 남는다.

6. 알파벳과 한글이 섞여있는 Array[String] 정렬

To-Do List를 관리하다보니 이 부분에서 에러를 경험했고, 이 부분은 별도의 글로 이미 작성했다.

7. babelHelpers is not defined

webpack 버전이 좀 옛날인, 갱신이 좀 구리구리한 vue template을 사용해서인지 babel-loader가 뜻하는 대로 작동하지 않았다. 아니면, babel-loader의 호환성 문제일까? 이 부분은 별도의 글로 이미 작성했다.

8. declare var twice

이 부분도 별도의 글로 이미 작성한 부분이다. 하지만 babel-minify의 time / space efficiency가 끔찍할 정도로 안 좋다는 것을 느꼈고, webpack을 config를 한 번 갈아 엎으면서 uglify-es 적용으로 해결된 부분이다. 최대한 babel-miniy의 사용을 피하는 편을 추천한다.

(uglify로 돌리면 25초정도, babel-minify로 돌리면 3분에서 4분정도가 소요됐고, 메모리도 무지막지하게 먹어서 월 2.5달러 서버에서 돌리기에는 1기가바이트 swapfile로도 부족해서 정상적으로 webpack compile을 수행할 수 없었다.)

9. IE Compatibility

신경 하나도 안 썼다. 오히려, 신경쓸 필요가 없다고 생각했다. 핸드폰의 배경화면에 바로가기를 만들어 내가 사용할 목적으로 (다른 사람들이 사용하는 건 겸사겸사ㅎ) 만들었으니, iphone7 safari에서 잘 돌아가면 그것으로 OK였다. 그 이상을 토이 프로젝트에 바라는 사람들은.. 어디보자.. 국민은행 966901…

10. Etc.

그 외에도 왜 vue를 썼는지, back-end는 무엇으로 작성해서 어떤 기능을 덧붙이고 싶은지, favicon / open graph와 같이 자잘한 것들을 어떻게 쉽게 생성하고 관리하는 지에 대해서도 써보고 싶지만, 내가 생각하는 이상적인 포스팅 당 내용이 벌써 훌쩍 넘은 것 같다.

back-end 부분을 포함해서 앞으로의 추가하고 싶은 / 다듬고 싶은 기능들 로드맵으로 하나의 포스팅, 그리고 나머지 주제에 대해서 하나씩 포스팅하는게 낫지 않을까 싶은데, 10월 말까지 졸업 프로젝트가 있어서 시험이 끝난 주말에 이렇게 포스팅을 몰아서 작성했다. 앞으로 또 한동안 포스팅을 기대하지 않는 것을 추천!

3 thoughts on “flurry.olaf.kr 개발 후기”

  • 홈페이지 너무 잘보고 있습니다 ^^
    얻어가는게 정말 많구요 도움 많이 받고있습니다
    염치없지만 요즘 olaf님 사이트보며 많이 배움 & 공부 하고있는데요

    개발중 궁금한게 한가지 있습니다
    제가 현재 Vue + WebPack + Express 를 사용하여 간다하게 홈페이지 만들고 있는데요

    프론트엔드 쪽에서 Vue + WebPack (8080 포트 사용) , 백앤드 쪽에서 Express (3000 포트사용)

    위에 처럼 서버를 두개 띄우는게 아닌 Vue + WebPack + Express (8080포트만 사용) 의 구성이 가능한가요?

    • 안녕하세요!
      node를 백엔드로 쓰며 거기서 같이 vue나 react를 프론트엔드에서 짜는 보일러플레이트를 사용하시는 게 가장 빠를 것같아
      요. 보통 그런 보일러플레잇을 isomorphic 이라고 많이 하던데,https://github.com/egoist/vue-isomorphic-starter 또는 https://github.com/ream/ream 를 참고하시면 될 것 같은데.. 전자는 업데이트가 안된지 9개월정도 넘었고, 후자는 아직 알파 버전이라서 애매하네요.
      isomorphic이나 ssr (server-side rendering) 을 키워드로 해서 찾아보면 원하는 솔루션을 찾으실 수 있을 거에요

Leave a Reply