작업 동기

트위터를 즐겨 쓴다. 나름 헤비 유저다. 트위터는 옛날부터 키보드 사용자를 배려해왔다. 트위터 화면에서 J,K 키를 입력하면 화면을 아래,위로 스크롤할 수 있다. VIM 사용자 입장에서 아주 자연스럽고 쾌적하다. 그런데 가끔 딱 시야를 방해하는 그 자리에 "새 트윗 보기" 팝업이 뜬다. 일단 팝업이 뜨면 가독성이 현격히 떨어진다. 쾌적하지 못하다.

그림 : 문제 현상

해결책을 찾기 위해 노력했다. 브라우저 개발자 도구를 열고 범인을 찾았다. 그리고 해당 html 요소를 투명하게 만들면 해결 가능함을 확인했다. 하지만 트위터를 켤 때마다 개발자 도구를 열고 콘솔창에서 "화면 청소 코드"를 실행시키는 것은 사람이 할 짓이 아니었다. 이런 건 분명 기계에게 시켜야 옳은 일이다. 그리고 나만 불편할까? 이 기능을 브라우저 애드온으로 만들어 공개한다면 널리 세상을 이롭게 하는, 단군 할아버지께서 기뻐하실 만한 일이 되지 않을까?

그림 : 범인

해결책 : 트위터 화면 청소 코드

obj = document.getElementsByClassName('r-dkhcqf'); for (o of obj) { o.style.opacity = 0.1 }

참조 코드를 찾자

모방은 창조의 어머니. 가장 먼저 할 일은 참조 코드를 찾는 일이다. 파이어폭스를 주력 브라우저로 쓰는 입장에서 아주 그럴듯한 참조 코드를 찾았다. webextensions-examples. 이름처럼 다양한 애드온 샘플로 구성된 프로젝트다. 제시된 애드온 샘플 중에서 borderify 샘플이 내게 잘 맞는다고 생각했다. borderify 애드온은 *.mozilla.org 페이지를 표시할 때마다 붉은색 테두리를 덧붙여 표시하는 애드온이다. 특정 url에 반응한다는 점(즉 트위터 url에 반응하는 애드온을 만들 수 있다는 점)과 브라우저 컨텐트를 대상으로 스크립트를 실행한다는 점(즉 트위터 화면 청소 코드를 실행시키는 애드온을 만들 수 있다는 점)이 내가 원하던 바였다.

몇 차례 시행착오 끝에 애드온 소스 코드를 완성했다.

애드온 GitHub 소스 레포

파이어폭스 주소창에서 about:debugging을 입력하고, "임시 부가 기능 로드..." 버튼을 선택해서 manifest.json 파일을 선택하면, 브라우저에서 애드온을 실행시켜 볼 수 있다. 그렇게 애드온이 정상 동작함을 확인했다.

그림 : 애드온 개발 설정

이제 개발한 애드온을 정식 등록할 차례다. 그러면 브라우저를 실행시킬 때마다 "임시 부가 기능 로드..." 버튼을 클릭하지 않아도 된다. 그리고 집에 있는 컴퓨터 뿐 아니라 회사에 있는 컴퓨터에서도 이 애드온을 사용할 수 있게 된다. 절차는 간단했다. AMO 개발자 허브에 등록하면 된다. 소스 코드를 zip 파일로 압축해서 클릭 몇 번만 하면 등록이 완료된다. 그러면 24 시간 이내에 처리 결과를 알려주겠다는 친절한 메일이 온다. 그리고 정말 그 다음날 애드온이 등록됐다.

그림 : AMO에 정식 등록된 애드온

그림 : 파이어폭스에 정식 설치된 애드온

브라우저 애드온은 나름 표준 웹기술이어서 파이어폭스 애드온을 조금만 다듬으면 크롬 브라우저에서도 사용 가능하다. 크롬 브라우저를 위한 나머지 일은 다른 훌륭한 사람에게 미룬다. 브라우저로 할 수 있는 재미난 일이 더욱 많아지기를 희망한다. 웹3 세상의 주력 플랫폼은 브라우저일 것이다.

성능테스트 도구 탐색

• JavaScript로 테스트 시나리오를 짤 수 있는 도구를 탐색
• 몇 년 전 사용했던 Artillery와 새로 알게 된 k6를 놓고 고민
• 미미하게 구글링 건수가 많고 (37,000건 vs 1,800건), grafana 대시보드가 멋진 k6를 선택
• k6 프로젝트의 오너가 grafana-labs라서 grafana와의 연계가 좋을 수 밖에 없음

사용법

• k6를 실행하려면 influxDB와 grafana가 있어야 함
• k6 + influxDB + grafana를 컨테이너로 실행하는 것이 가장 간편
• k6 소스레포에서 docker-compose.yml 파일을 제공함  

git clone https://github.com/grafana/k6 && cd k6 
git submodule update --init 
docker-compose up -d influxdb grafana
docker-compose run -v $PWD:/scripts k6 run /scripts/myscript.js

테스트 스크립트 작성

• k6 자체는 go 언어로 작성됨
• k6에서 실행되는 테스트 스크립트는 JavaScript로 작성함
• 테스트 스크립트는 반드시 default function을 export 해야 함
• 해당 function을 k6가 생성하는 VU(virtual user)들이 실행함

import http from "k6/http";

export default function() {
    let response = http.get("https://test-api.k6.io");
};

실행 팁

• grafana 커뮤니티에서 만든 대시보드들 중 4411 추천
• k6 성능테스트 도중 "The flush operation took higher than the expected set push interval" 에러를 만남
  ==> influxDB에 테스트 지표를 write 하는 시간이 지연되어 발생하는 에러
  ==> 테스트 결과 분석에 필요한 지표만 SystemTags로 지정해서 influxDB의 지표 수집 부담을 줄여준다

export let options = { 
   vus: 4, 
   stages: [ 
     { duration: "30s", target: 32 }, 
     { duration: "60s", target: 32 }, 
     { duration: "30s", target: 4 }, 
   ], 
   systemTags: ['status', 'http_req_duration'], // <== 이거!
};

Ref

https://k6.io/blog/k6-loves-grafana/

• k6 실행 방법과 대시보드 설치 방법을 간결하게 설명

https://github.com/grafana/k6

• k6 소스레포 (README 내용 좋음)

https://k6.io/docs/

• k6 공식 문서

2020.10.15.

어찌어찌 프로젝트가 살아남았고 간단한 Admin 포털을 또 만들 기회가 있었다.

지난번에 이어 이번에도 개발 소감을 요약해본다 (2020.10.15. 기준).

개발환경: win10 좋다
- OS: win10 + wsl + windows terminal
- tool: vim, tmux, nodejs, vue-cli
- framework/lib: vue, vue-router, vuetify, vuex, axios
- runtime: firefox + vue dev-tools

프론트엔드 프레임워크: Vue 좋다

- 컴포넌트
  . 통상 웹UI 컴포넌트 하나를 구현하려면 html, css, js 3개 파일이 필요
  . Vue는 UI 컴포넌트 하나를 하나의 파일로 정의 (SFC: Single File Component)
  . 개발/관리 측면에서 좋았음
- 급격하지 않은 변화
  . 개발 진행중에 Vuetify 문서가 버전업됨
  . 하지만 변화 폭이 크지 않아서 쉽게 적응할 수 있었음
  . Vue 프레임워크 자체도 곧 3.0으로 버전업될 예정. 하지만 Vue 2.0과 크게 다르지 않을 예정
  . "변화 폭이 크지 않고, 변화 방향이 합리적"인 것이 프레임워크의 중요한 장점이라 생각함

디버깅툴: Firefox + Vue Dev-tools 좋다

- Vue dev-tools의 vuex 히스토리 기능이 큰 도움 됨
  어플리케이션의 상태 정보를 확인해서 해결되는 문제가 (생각보다) 많았음
- vuex의 mutation은 존재 의미를 불신하던 기능 (필요 없다 생각했음)
  Vue dev-tools 활용만으로도 vuex mutation의 가치를 느낌

프론트엔드 TDD: 정말 유용한가?

- 백엔드 tool을 개발하면서 TDD의 유용성을 체감함
- 그래서 프론트엔드 개발에도 TDD를 적용하는 것이 도리일 것이라고 생각,
  이번 작업에서 프론트엔드 TDD를 시도해봄
- 구현 코드보다 테스트 코드를 먼저 작성하면서 개발 요구사항을 정리해봄
  생각을 정리한다는 측면에서 나름 의미는 있었지만,
- 프론트엔드 테스트 코드는 구현 코드와 밀결합될 수 밖에 없음을 느낌
  그리고 프론트엔드의 문제점은 테스트 코드보다 눈과 손으로 먼저 체크하게 됨을 느낌
- 테스트 코드를 작성하는 번거로움 대비 실익을 느낄 수 없었음
- 단기간(3달) 동안 거의 혼자 하는 개발이어서 그랬을지도 모름. 베스트프랙틱스에 대한 조언을 구함

(이상)

2021-04-25.

HTML 태그의 data- 속성을 이용해서 실제 구현 코드와 테스트 코드의 의존성을 분리할 수 있다는 조언을 들었다.

예를 들어 화면에 표시되는 메시지 문자열을 검증하는 테스트 코드를 만들 경우, 특별한 data- 속성 (예를 들어 data-test-id="message")을 가진 HTML 요소를 찾아 그 문자열을 검증하면 된다. 이렇게 하면 개발자가 해당 문자열을 표현하기 위해 어떤 HTML 태그를 쓰는지, 어떤 id를 쓰는지 같은 세세한 구현 디테일과 분리된 테스트 코드를 작성할 수 있다. 그러면 차후 HTML 구조가 바뀌거나 엘리먼트 id가 바뀌어도 테스트 코드는 변경 없이 유지할 수 있다.

2022-03-14.

프론트엔드 TDD에 관한 좋은 책을 발견해서 많이 배웠다.

Testing Vue.js Applications

-- Edd Yerburgh 지음

-- Manning 펴냄

-- https://www.manning.com/books/testing-vue-js-applications

책 구석구석에서 Vue.js와 TDD에 대한 저자의 풍부한 경험을 배울 수 있었다.

무엇보다 TDD에 관해 "하면 안되는 것들" 을 분명히 일러주는 것이 좋았다.

• 무엇을 테스트할지 결정하는 것이 핵심이다 - 가능한 적게 테스트하라
  • 개발환경/실행환경 설정에 관한 유닛 테스트를 하지 마라
  • 화면 스타일에 관한 유닛 테스트를 하지 마라
• 유닛 테스트, 스냅샷 테스트, e2e 테스트가 모두 필요하다
• 유닛 테스트를 많이, 스냅샷 테스트는 조금만, e2e 테스트는 더 조금만 하라

TDD를 시작하면서 잘 해보려는 의욕 때문에 테스트 케이스를 가능한 많이 작성하려 했다. 특히 HTML 요소들이 화면에 제대로 표시되는지까지 유닛 테스트로 확인하려 했다. 이 책 덕분에 그러면 안된다는 것을 알게 됐다 (테스트 케이스는 가능한 적게 작성해야 하고, 화면 출력에 관한 테스트는 스냅샷 테스트로 커버해야 한다는 것을 알게 됐다).

2019.10.19. 개발 계획을 정리함
2019.12.23. 개발을 마치고 소감을 추가/정리함

0. 배경

• 간단한 Admin 포탈을 개발해야 하는 상황을 맞이함
• 이에 웹 프론트엔드 개발에 사용할 기술스택을 조사, 그 선택 과정과 결과를 공유함
• 선택 과정에서 https://bestofjs.org 의 자료가 유용했음

1. 웹 프론트엔드 프레임워크

• React.js vs. Vue.js 를 고민
• React.js
  • 페이스북이 개발
  • Virtual DOM 개념을 활용한 빠른 화면 처리 (Virtual DOM 개념의 원조)
  • MIT 라이선스 (페이스북 독자 라이선스 모델이었으나 커뮤니티의 요구로 변경됨)
• Vue.js
  • 커뮤니티가 개발
  • Virtual DOM 개념을 활용한 빠른 화면 처리 (Virtual DOM 개념 따라쟁이)
  • MIT 라이선스 (상용 사용이 가능한 무료/오픈소스 라이선스)
• 결론: Vue 선택
  • React.js가 잘 팔린다는 말에 고민했으나 Vue.js 학습 난이도가 낮다는 말에 Vue.js로 결정

Virtual DOM?
브라우저 안에서 DOM-tree 조작 (HTML 요소의 추가/삭제/변경)이 일어나면
이후 Render-tree를 만들고 이를 화면에 출력하는 프로세스가 진행됨.
이는 처리비용이 큰 프로세스여서 DOM-tree 조작을 줄일수록 화면 처리 성능이 개선됨.
Virtual DOM은 별도의 메모리 공간에서 DOM-tree 조작 작업을 수행한 다음
최종 결과만 실제 DOM-tree에 복사해서 브라우저 화면을 갱신하는 방식 (그래서 화면 갱신을 최소화 하는 방식).

==> 2019.12.23. 회고
Vue.js 선택에 후회 없었다. 처음 생각처럼 학습 장벽이 극히 낮아서 쉽게 배워 쓸 수 있었다. Vue.js의 SFC (Single File Component) 개념은 아주 멋졌다. 다음 프로젝트가 있다면 주저없이 Vue.js를 계속 쓸 것 같다.

2. UI 컴포넌트 라이브러리

UI 컴포넌트 라이브러리?
디자인된 UI 구성요소들(버튼, 콤보박스, 리스트박스 등의 화면 구성요소들)의 모음

• Bootstrap vs. Vuetify 를 고민
• Bootstrap
  • 트위터가 개발한 역사와 전통의 UI 컴포넌트 라이브러리
  • 반응형 웹디자인 (모바일 화면과 데스크탑 화면을 적절히 지원)
• Vuetify
  • 커뮤니티가 개발
  • 구글이 제안한 '머티리얼라이즈 디자인' 제공 (플랫 스타일 디자인)
• 결론: Vuetify 선택
  • Vue 프로젝트와 궁합이 더 좋을 것 같다고 생각

==> 2019.12.23. 회고
Vuetify 선택에도 후회 없었다. Bootstrap의 Grid System을 거의 그대로 지원한다. 그래서 반응형 UI (Responsive UI)를 만들기 좋았다. 라이브러리의 개념체계가 직관적이어서 Bootstrap보다 사용법이 쉽다고 느꼈다. 특히 문서가 정갈하고 좋았다.

3. 모듈 번들러

모듈 번들러?
브라우저와 서버 사이의 통신비용을 낮추고 처리속도를 높이기 위해,
브라우저 안에서 실행될 여러개의 JS 파일들을 한개의 파일로 묶어주는 도구

• Webpack vs. Browserify 를 고민
• Webpack
  • JS 파일 뿐 아니라 HTML, CSS, 이미지 파일들도 번들링 가능
• Browserify
  • JS 파일만 번들링
• 결론: Webpack 선택 (별로 고민할 거리가 없었음)

==> 2019.12.23. 회고
이건 vue cli가 만들어주는 틀을 그냥 따랐던 것이 잘했던 것 같다. 내가 무엇을 선택해서 쓴다는 느낌이 들지 않았다. 모든 것이 자연스러웠다.

4. 테스트 프레임워크

• Mocha vs. Jasmine 을 고민
• 결론: Mocha 결정 (별로 고민할 거리가 없었음)

==> 2019.12.23. 회고
UI를 위한 유닛 테스트를 작성하지 않았다. 이번 개발 범위가 워낙 단촐해서 테스트 코드를 만드는 것이 오버헤드라고 판단했다. 하지만 이 프로젝트가 살아남는다면 반드시 해야 할 일이라고 생각한다 (다음을 기약).

(이상)

어쩌다보니 혼자 하게 된, ES6에 대한 아주 알찬 소개. 정성을 다해 번역했습니다.

ES6 in depth

http://hacks.mozilla.or.kr/category/es6-in-depth/

Backbone.js를 써서 프론트엔드 웹앱을 만들 때 폴더 구조와 파일 이름을 어떻게 정할까 고민스러웠는데, 비슷한 고민을 담고 있는 블로그 기사가 있어 요약한다.

• JavaScript는 폴더/파일의 구조 및 이름에 대해 규정하는 바가 전혀 없다.
• 그러니 당신이 어떻게 하고 있더라도 "당신은 옳다".
• 개인적으로 Backbone 등 MVC framework을 사용하는 경우 models, collections, views 등 타입별로 폴더 구조를 가져가는 것에 반대한다.
• contact, mail 등 업무나 역할 별로 폴더 구조를 만들고,
• person.js (model), persons.js (collection), personview.js, personrouter.js 처럼 파일 이름에 타입을 명시하는 방식을 선호한다.
• 하지만, 다시 한번 말하지만 당신이 어떤 결정을 하더라도 "당신은 옳다"

JavaScript File & Folder Structures: Just Pick One

asm.js에 대하여

배경

- 파이어폭스 팀에서 개발

- 파이어폭스 차기버전 JavaScript 엔진(OdinMonkey)이 asm.js 지원 예정

- 모질라에서 asm.js를 이용하여 Epic의 언리얼 엔진3(heavy한 게임엔진)를 시연함

개요

- JavaScript의 subset

- 새로운 언어가 아님

- 기존 모든 브라우저에서 실행 가능함

- asm.js를 지원하지 않는 JavaScript 엔진도 asm.js 코드를 실행시킬 수 있음

- 변수 타입을 엄격하게 체크하는 문법을 정의(기존 JavaScript는 변수 선언시 타입을 지정하지 않음)

- 변수 타입을 엄격하게 정의하면 JIT(실행시간 컴파일) 뿐 아니라 AOT(Ahead Of Time: 실행전 컴파일)이 가능해짐

- 파이어폭스는 조만간 asm.js에 최적화된 컴파일러를 제공할 예정이며 벤치마크 결과는 "경이적"

전망

- 모질라는 기존 언어로 개발된 코드를 asm.js 코드로 변환해주는 도구 제공을 약속

- 특히 엄격한 타입 체킹 언어인 C/C++은 asm.js 코드로 변환하기에 최적인 언어

Reference

- Big Web App? Compile It! 

   http://kripken.github.io/mloc_emscripten_talk/#/

- [번역] asm.js : 컴파일러를 위한 low level, 고도로 최적화 가능한 JavaScript의 서브셋

   http://atconsole.com/2013/04/04/%EB%B2%88%EC%97%AD-asm-js-%EC%BB%B4%ED%8C%8C%EC%9D%BC%EB%9F%AC%EB%A5%BC-%EC%9C%84%ED%95%9C-low-level-%EA%B3%A0%EB%8F%84%EB%A1%9C-%EC%B5%9C%EC%A0%81%ED%99%94-%EA%B0%80%EB%8A%A5%ED%95%9C-javascript/

- asm.js에 대해서

   http://blog.outsider.ne.kr/927

(끝)

JavaScript 빌드 도구(build tool) 동향 요약

스캐폴딩(scaffolding) 기능을 중심으로...

보일러플레이트(boilerplate) 도구

- 보일러플레이트는 코드 재사용을 위해 코드 골격을 미리 구성해 놓은 것

백본 보일러플레이트(backbone boilerplate)

- Backbone.js 프레임워크를 이용하는 프로젝트를 위한 보일러플레이트

- 소스 위치: https://github.com/tbranyen/backbone-boilerplate

- 다른 백본 보일러플레이트도 있지만 이 프로젝트가 제일 좋음 (스스로 좋다고 주장함)

    - requireJS를 잘 지원

    - 라이브러리 소스를 있는 그대로 (변형하지 않고) 사용

    - 빌드 시스템을 구비

    - 샘플 앱을 지원

    - 필요한 골격만 지원

스캐폴딩

- 스캐폴딩은 MVC f/w 특히 RoR(루비 온 레일즈)에서 널리 사용되기 시작함

- 어플리케이션 구축에 필요한 뼈대를 자동 생성해주는 기능

- 기본 파일과 디렉토리 구조를 매번 새로 만들어야 하는 번거로움을 제거

grunt

    - grunt는 node.js 기반의 JavaScript 빌드 도구

    - 설치방법: node.js가 설치된 상태에서 npm install 명령을 이용 설치

        - node.js는 이제 JavaScript 실행환경일 뿐 아니라 훌륭한 개발환경

    - package.json 파일에 grunt 실행에 필요한 모듈 서술

        - 프로젝트 root에 두며 소스 버전 관리 대상

        - npm install 명령을 실행하면 필요한 모듈이 자동 설치됨 ( 다시 말하지만, node.js는 이제 훌륭한 개발환경! )

        - npm init 명령으로 기본적인 package.json 파일을 생성함

    - gruntfile.js 파일에 일괄 처리할 작업을 정의

        - make 시스템의 makefile에 해당

        - grunt 0.3.x 버전에서는 gurnt.js로 통용됨 

        - grunt 0.4.x 버전에서 gruntfile.js로 이름 변경됨

        - 프로젝트 root에 두며 소스 버전 관리 대상

        - grunt plugin이 package.json에 들어 있고, 

            npm install 명령으로 설치됐다면, 

            gruntfile로 쉽게 실행시킬 수 있음

        - pkg 섹션

            - pakcage.json을 가리키는 역할

            - package.json에는 프로젝트 관련 메타데이터가 정의됨

            - pkg.name 같은 형태로 메타데이터 참조가 가능

        - meta 섹션

            - 내부 속성으로 banner만 있음

            - 합치거나 축약할 때, js 파일 상단에 자동으로 넣는 주석 지정

        - lint 섹션

            - JSHint를 이용 JavaScript 파일 테스트

            - 테스트할 파일 목록을 자유롭게 grouping하여 지정 가능

        - qunit 섹션

            - jQuery의 테스트 프레임워크인 QUnit을 이용 테스트 수행할 대상 파일을 지정

            - PhantomJS가 설치되어 있어야 함

            - lint 섹션처럼 테스트할 파일 목록을 자유롭게 지정 가능

        - concat/ min 섹션

            - 파일을 합치거나(concat), 공백을 제거해서 축약(min)시키는 작업을 실행

        - watch 섹션

            - 지정된 파일이 변경될 경우, 지정된 작업을 수행

        - jshint 섹션

            - lint 섹션을 실행할 때, JSHint 툴에 전달할 옵션 정의

            - 실행 섹션이 아님

        - uglify

            - min 섹션을 실행할 때, UglifyJS 툴에 전달할 옵션 정의

            - 실행 섹션이 아님

grunt-bbb

    - grunt-bbb는 grunt의 플러그인

    - bbb는 Backbone Boilerplate Build를 뜻함

    - npm install -g bbb 명령으로 설치 ( 다시 말해 node.js는 이제 정말 훌륭한 개발환경! )

    - 사용 명령어

        - init (bbb)

            - bare boilerplate 프로젝트 생성

        - init:module (bbb)

            - 새로운 모듈 생성

            - model, collection, view를 통합하는 module 생성

            - js, css, html 생성

        - server (bbb)

            - 웹서버를 띄워 프로젝트를 실행

Reference

- http://blog.outsider.ne.kr/892

- https://github.com/tbranyen/backbone-boilerplate/wiki/Getting-started-overview

- https://github.com/tbranyen/backbone-boilerplate/wiki/Installation

- http://gruntjs.com/

- https://github.com/backbone-boilerplate/grunt-bbb

Modern Javascript WebApp 동향

+ SPA : Single Page Application

- 하나의 HTML 파일(Single Page)에 여러 화면을 담아 제공

- 화면이 바뀔 때마다 새로운 HTML 파일을 읽어들일 필요가 없어지기 때문에 응답성이 개선됨

- WebApp의 현재 상태/화면을 hash-url(한 HTML 페이지 안의 위치를 나타내기 위해 사용하는 #으로 시작되는 http://some.domain.com/some-page.html#some-location 과 같은 형태의 URL)로 관리

- hash-url을 이용하여 WebApp의 상태/화면 관리하는 개념을 Routing이라고 하고, hash-url을 해석해서 WebApp의 상태/화면을 관리하는 모듈을 Router라고 함

+ Off-line enabled WebApp

- HTML5의 off-line 지원 기능을 활용, 네트웍에 연결되어 있지 않아도 로컬에 캐시된 WebApp 코드를 이용해서 WebApp을 실행

- Off-line enabled WebApp이 되려면 서버의 도움 없이 실행될 수 있도록 모든 프로그램 로직이 front-end에 존재해야 함

+ BaaS : Back-end as a Service

- WebApp의 front-end에 모든 로직을 담고 정형화된 back-end를 RESTful API 형태로 제공하는 개념

- Back-end가 제공하는 데이터를 가공하는 모든 로직은 front-end에 존재해야 함

=> SPA, Offline enabled Web App, BaaS 등 Modern JS WebApp은 기본적으로 규모가 큰 front-end 코드를 요구함

=> front-end code의 규모가 커짐에 따라 소스코드의 유지/보수 비용을 절감하기 위해 MVC 패턴을 이용해서 WebApp 코드를 구조적으로 만들 필요가 생김

MVC 디자인 패턴

+ 디자인 패턴이란?

- 재사용 가능한 소프트웨어 디자인(설계)

- 검증된 문제 해결 방식

- 필요에 따라 유연하게 적용 가능

+ MVC 패턴이란?

- Model, View, Controller로 소프트웨어 구조를 나눔

- Model은 데이터를 표현

- View는 화면(보통 아무런 로직도 없음)을 표현

- Controller는 M과 V 사이의 조율, 비즈니스 로직을 처리

- 전통적으로 서버-사이드에서 많이 사용됨

MVC를 지원하는 Javascript f/w 종류

+ JavaScriptMVC

- 완성도 높은 성숙한 기술

- all-in-one 솔루션

- 대규모 프로젝트에 적합

- GrooveShark(미국의 음원 제공 서비스)에 적용됨

+ Backbone.js

- 경량

- SPA 제작에 최적

- 다른 컴포넌트와 함께 사용하기 좋음

- MetaLab, SoundCloud, BitTorrent 등에 적용됨

+ Spine.js

- 경량

- Class 개념 제공

- Backbone API에 기초하여 Backbone 개발자라면 추가 학습 비용이 낮음

+ Sammy.js

- Route 기반 앱 개발에 적합한 경량 프레임워크

- Controller만 제공 (M과 V를 제공하지 않음)

- PaperlessPost에 적용됨

+ SproutCore

- 데스크탑 어플 같은 Rich함을 지향하는 앱 개발에 적합

- 대규모 엔터프라이즈 앱 개발에 적합

- 애플 MobileMe에 적용됨

Reference

- MVC and the Web

http://kanian77.wordpress.com/category/software-engineering/mvc/mvc-and-the-web/page/3/

- Tools For jQuery Application Architecture (Extended Slides)

http://addyosmani.com/toolsforjqueryapparchitecture/

- 자바스크립트 웹어플리케이션 개발경험기

http://blog.outsider.ne.kr/787

- Digesting JavaScript MVC ? Pattern Abuse Or Evolution?

http://addyosmani.com/blog/digesting-javascript-mvc-pattern-abuse-or-evolution/

- Scaling Isomorphic Javascript Code

http://blog.nodejitsu.com/scaling-isomorphic-javascript-code

- MVC Architecture for JavaScript Applications

http://michaux.ca/articles/mvc-architecture-for-javascript-applications