안녕하세요, DevOps팀의 왕왕 입니다.오늘 소개할 내용은 이번 프로젝트에서 Vue.js를 사용하면서 효율을 극대화하고 더 큰 생산성을 낼 수 있게 해주었던 Vuex와 Nuxt.js 입니다. Vue를 단독으로 사용했을 때가 그냥 커피라면 Vuex와 Nuxt.js가 첨가된 Vue는 T.O.P라고 할 수 있답니다 :) 먼저 Vuex 입니다.  Vuex는 Vue.js의 상태(state)관리 패턴이자 라이브러리 입니다. 컴포넌트 간 데이터 활용이 더욱 용이해집니다. * Vue.js에서 컴포넌트 간 공유할 수 있는 데이터를 흔히 상태(State)라고 부릅니다.  “State =  공유하는 데이터” 라고 이해하시면 되니 오해하지 말아주세요! Vue.js에 대해서 공부하신 분들이면 의문을 가지실 수도 있습니다. Vue.js에서 기본으로 제공하는 emit, prop, ref 등으로 컴포넌트 간 데이터를 주고받을 수 있기 때문이죠. 하지만 어플리케이션이 복잡해질 수록 다음과 같은 한계가 생기게 됩니다. 1.    데이터를 공유하는 컴포넌트의 수가 많아지고 중첩되기 까지하면 유지보수가 힘든 코드가 되어버린다.2.    여러 컴포넌트에서 데이터를 변경하려는 액션이 일어날 때 컴포넌트 간 데이터 공유/관리가 복잡해진다. [Vuex를 사용하지 않은 데이터 흐름]데이터가 부모-자식 혹은 형제에게 전달되는 과정이 한 눈에 봐도 복잡해 보입니다 :([Vuex를 사용한 데이터 흐름]위 그림 처럼 Vuex는 전역에서 저장소 역할을 하는 Store가 있습니다.미리 api를 호출하여 store를 DB에서 불러와 세팅할 수 있고, 각 컴포넌트에서 접근/변경이 가능합니다. 이를 통해 Vuex에서는 더욱 직관적이면서 효율적인 데이터 관리가 가능해집니다.Vuex의 패턴Vuex는 Flux 패턴에서 창안되어 사용되고 있습니다. MVC 패턴의 문제점을 보완하여 양방향이 아닌 단반향 데이터 흐름의 개발 패턴입니다. Vuex는 Store에서 모든 상태관리가 이루어집니다.아래는 컴포넌트에서 액션이 일어나 UI가 갱신되기 까지의 Vuex 패턴의 흐름입니다.1.    컴포넌트가 Action을 일으킨다. 2.    Action에서는 API 등을 호출해 그 결과를 이용해 Mutate를 일으킨다.3.    Mutate에서는 Action의 결과를 받아 State를 변경시킨다. 이 과정은 추적이 가능하다.4.    Mutate에서 변경된 State는 다시 컴포넌트에 바인딩되어 UI를 갱신한다.[개발자 도구에서 쉽게 확인가능한 Event들](Mutation이 발생한 이력을 추적할 수 있다!)(Action도 마찬가지)이런 단방향 데이터 흐름 덕에 예측이 가능하도 추적 역시 가능합니다. Store을 사용한 중앙 집중식 관리로 결합도가 낮은 것도 장점이네요. -다음으론 Nuxt js입니다.!Vue.js의 든든한 지원군 Vuex에 이어 Vue.js 어플리케이션 개발을 보다 쉽게 만들어주는 프레임워크 Nuxt.js에 대해서 알아보겠습니다.Nuxt.js는 Vue.js 프로젝트에서 사용되는 여러 유용한 라이브러리들

January 6, 2022 37 min to read 안녕하세요, 포털개발팀 프론트파트의 신입 개발자 김선규 입니다. 이번 글은 파일럿 프로젝트로 진행하게 된 줌인터넷 댓글 모듈 개선과정에 대한 내용입니다. TL;DR JavaScript, jQuery 기반으로 이루어진 댓글 모듈 Vue, TypeScript 로 개선 TDD(테스트 주도 개발)로 프로젝트를 진행 댓글 모듈 컴포넌트 사내 라이브러리 배포 줌 소셜 댓글 모듈 현재, 줌인터넷의 서브 도메인(투자, 뉴스, 허브 등)은 모두 사진과 같은 댓글 모듈을 통해서 댓글을 입력하고 답글을 달게 됩니다. 문제점 여러 가지 문제점들을 설명하기에 앞서서, 왜 기존의 댓글 모듈을 개선하는 프로젝트를 담당하게 되었는지 간략하게 설명하겠습니다. 줌인터넷 기존의 서비스들은 MPA(Multi Page Application)로 구성이 되어있었습니다. 댓글 모듈도 이에 맞추어 페이지가 전환될 때마다 스크립트를 주입하는 방식으로 짜여 있었습니다. 기능적인 부분에서는 문제가 없었지만, 프론트엔드파트가 SPA(Single Page Application)로 서비스를 전환하는 과정에서 불편함을 겪게 되었고, 이러한 불편함을 해결하기 위해서는 기존의 댓글 모듈을 SPA에 맞추어 개선해야 하는 필요성이 있었습니다. 불편함을 주었던 아래의 문제점들은 새로운 기능을 추가하거나 유지보수 하는 것을 어렵게 만들었습니다. 페이지 전환 시 댓글 모듈 스크립트를 주입 최상위 document에 등록된 모든 이벤트 상태 추적의 어려움 가독성 언제 쓰이는지 파악하기 어려운 코드 덩어리들 페이지 전환시 스크립트를 브라우저에 주입하는 방식의 문제 기존의 MPA 방식에서는 댓글 모듈을 사용하기 위한 일련의 작업이 필수적으로 필요했습니다. HTML에 특정 엘리먼트를 삽입 jQuery를 사용하기 위한 스크립트 추가 초기화 스크립트 등록 <!-- HTML에 해당 엘리먼트 삽입 필요 --> <div id="zca_main" class="zum_social_comment_wrap"></div> <!-- jQuery 사용 --> <script src="https://code.jquery.com/jquery-1.12.4.min.js"></script> <script src="/plugin/zum-comment/js/jquery.cookie.js"></script> <!-- 초기화 스크립트 --> <script th:inline="javascript"> document.domain = 'zum.com'; function zav_callback() { var sysCode = [[${sysCode}]]; var articleIdx = [[${articleIdx}]]; var zav = new Zav(); zav.options.displayBtn = 'like'; zav.init(sysCode, articleIdx); } function zca_callback() { var sysCode = [[${sysCode}]]; var articleIdx = [[

October 1, 2021 69 min to read 안녕하세요, 줌인터넷 포털개발팀 프론튼엔드 파트리더 황준일입니다 ‍️ 오랜만에 기술블로그에 투고를 하네요. 어떤 글을 주제로 글을 작성해야 유익할까 꽤 오랜 시간 동안 고민을 했습니다. 이번에는 제가 실무를 하면서 생각보다 꽤 많은 삽질을 했던, SSR(Server Side Rendering)을 주제로 다뤄보도록 하겠습니다. 본 포스트는 모바일 줌 SpringBoot NodeJS 전환기 (feat. VueJS SSR)을 먼저 읽어보면 더 유익합니다. 이 글을 읽고 있는 많은 분들이 SSR에 대한 개념은 이미 숙지하고 있으리라 생각합니다. 그럼에도 불구하고 한 번 SSR의 개념적인 부분을 정리해보겠습니다. (1) 무엇(What) 인가 저는 웹 개발을 PHP로 접했습니다. PHP는 Hypertext Preprocessor의 약자인데, 해석해보면 HTML 전처리기라는 의미입니다. 전처리기라는 단어가 익숙하지 않나요? 프론트엔드 개발자들이 많이 사용하는 SASS, LESS 등이 바로 CSS의 전처리기(Preprocessor)입니다. 대충 어떤 느낌인지 감이 오시나요? 반대로 PostCSS 같은 후처리기도 존재한답니다! 즉, PHP를 이용하여 HTML을 동적으로 만들어낼 수 있는 것입니다. 이와 비슷한 도구로 JSP와 ASP도 있습니다. 완전 똑같진 않지만, JSP(Java Server Page)와 ASP(Active Server Pages)도 존재합니다. 그리고 이것들이 약 10년전쯤에 웹 개발의 생태계를 주름잡고 있던 3대장이었습니다. 이들의 공통점은 HTML을 Server에서 정제하여 출력해주는 도구입니다. 더 쉽게 말해서 SSR(Server Side Rendering)을 해주는 도구라고 볼 수 있습니다. 조금 딴 길로 접어든 것 같은데, 정리하자면 SSR은 Server에서 HTML을 정제하여 출력해주는 기법이라고 볼 수 있습니다. (2) 왜(Why) 필요한가 사실 이게 제일 중요한 주제입니다. 왜 SSR을 해야 할까요? 사실 앞서 언급한 것 처럼 전통적인 웹 개발은 이미 SSR을 이용했습니다. 그런데 브라우저가 발전하는 과정에서 Javascript 라는 언어 또한 점점 성숙해졌고, Javascript로 할 수 있는 일들이 점점 많아지게 되었습니다. 그러면서 DOM을 점점 더 정교하게 다뤄야했고, jQuery 같은 라이브러리로는 한계가 있었습니다. 그래서 구글에서 Angular를 만들었고, 이어서 페이스북에서는 Component 기반으로 개발할 수 있는 React를 만들었습니다. 다시 Angular와 React의 장점만 수용하여 만든 Vue도 등장했죠. 이런 프레임워크의 등장으로 모든 렌더링을 전부 브라우저(클라이언트)에게 위임했고, 이를 전문으로 하는 프론트엔드 개발자들이 필요해졌습니다. 프론트엔드 개발자들이 주로 하는 일이 바로 CSR(Client Side Rendering)인 것이죠. 그런데 CSR에는 서비스적인 한계가 존재합니다. 기본적으로 브라우저가 서버에서 받아오는 최초의

July 21, 2021 29 min to read 파일럿 프로젝트 줌인터넷 서비스개발팀 프론트엔드 파트 주니어 개발자들(재민, 도경, 정훈)이 수습 기간 동안진행했던 파일럿 프로젝트 입니다. 진행된 프로젝트는 GitHub 레포지토리에서 확인하실 수 있습니다. 목차 프로젝트 개요 1.1 프로젝트 주제 1.2 요구사항 1.3 프로젝트 기능소개 협업 방법 프로젝트 구조 3.1 프로젝트 전체 구조 3.2 패키지별 구조 3.3 Backend 구조 3.4 Frontend 구조 3.5 common 구조 기술적 고민 4.1 재민 님의 고민 4.2 도경 님의 고민 4.3 정훈 님의 고민 회고 5.1 재민 님의 회고 5.2 도경 님의 회고 5.3 정훈 님의 회고 마치며 파일럿 프로젝트의 의의는 미리 실무를 위한 웹 서비스 기반 지식, 기술을 습득하여 신규 입사자들이 보다 빨리 실무에 적응할 수 있도록 하는 데 있습니다. 그리고 파일럿 프로젝트가 끝나면 바로 줌닷컴 신규 서비스 개발 프로젝트에 투입될 예정이었습니다. 미리 도메인에 대해 학습케하여 더욱 실무 적응을 돕고 프로젝트를 성공적으로 수행할 수 있게끔 하고자 했습니다. 두 마리 토끼를 잡을 수 있도록 주제를 선정해야 했습니다. 그래서 .. 모바일 INVESTING.COM 앞으로 진행될 프로젝트에선 주식, 원자재, 가상화폐 등의 자산들을 폭넓게 다룰 예정입니다. 많은 투자 지표들을 상세히 다루고 캔들 차트, 라인 차트 등 풍부한 그래픽 자료를 제공해야 합니다. 그러한 컨텐츠를 이미 제공하고 있는 INVESTING.COM 이 있었습니다. INVESTING.COM 은 전세계 거래소 250곳의 실시간 데이터, 관련 뉴스 및 분석을 44개의 언어로 제공하는 금융시장 플랫폼입니다. 월간 2,100만 명의 이용자를 자랑합니다. 투자자들이 한 번에 필요한 정보를 모두 확인할 수 있는 장소를 제공하는 것을 목표로 하고 있습니다. 이러한 서비스를 클론 코딩하면서 기술적, 도메인적 이슈를 해결하는 경험, 실무에 필요한 지식 및 기술을 얻을 수 있으리라 생각했습니다. 이러한 이유로 INVESTING.COM 을 클론 코딩 하기로 했습니다. 개발은 5. 10 ~ 6. 24 까지 약 7주간 이루어졌습니다. 1.2. 요구사항 1.2.1 기술적 요구사항 필수 공통 zum-portal-core-js (사내 라이브러리) 완벽 이해 및 사용 Front-end Vue.js 2 Webpack 차트 Canvas API, SVG API를 이용해서 직접 만들어보기 그 후 ChartIQ, Highcharts 등 응용해보기 성능 최적화 초기 렌더링 SSR, 이후 CSR 사용 번들 용량 최적화 비즈니스 로직에 TypeScript 사용 SASS 사용 비동기 프로그래밍 최적화 (로딩 전/후 처리) Back-end Node.js + Express.js + Typescript 사용 Cache + Scheduling 적극 사용 주식 관련 외부 API는 자유롭게 선택 사용 회원 시스템 OAuth 2.0 (구글 로그인) JWT 인증 이메일/ 비밀번호/ 닉네임