REST API 주소구조

  • /board
    get – list
    post – write
    • /{id}
      get – read one
      put – modify one
      delete – remove one
    • /search
      post – search list -보통은 list에 포함
    • /batch
      get – read by ids
      post – write write write
      put – modify by ids? 일괄로 변경 할 일이…
      delete – remove by ids
route(Constants.URI_COMMENT_BASE) {
    get { }
    post { }
    route("/{id}") {
        get { }
        put { }
        delete { }
    }
    get("/search") { }
    route("/batch") {
        get { }
        put { }
        delete { }
    }
}

어떻게 할까 맨날 고민하는데 위는 표준구조로 잡아놓은 형태

rest가 되지 않는 경우는 과감히 포기

ex) 입금관련기능

  • /deposit/apply
  • /deposit/cancel
  • /deposit/confirm
  • /deposit/status

특정 도메인 영역이 있는 경우 rest API에 맞추기 힘들다

주소에 집착하지말자

  • /deposit/apply POST
  • /deposit/cancel POST
  • /deposit/confirm POST
  • /deposit/status GET

웹사이트 사용기술 알아내는 방법

직접 확인방법

공개된 정보 활용

  • 커뮤니티 질문 또는 글 검색
  • 해당 서비스 채용글 확인
  • StackShare 등의 사이트에 공개된 정보 확인
  • 해당 서비스의 기술블로그

기술적으로 확인

  • HttpHeader, Response 확인
  • 관용적으로 사용되는 주소 패턴 확인
  • Html 메타데이터 확인
  • CSS/JS 형태확인(컴파일?/소스형태)
  • Static파일의 서비스 형태

서비스 사용

이런걸 궁금해 하는 사람들을 위해 주소만 입력하면 확인할 수 있도록 도와주는 서비스가 많이 있다.

W3Techs (https://w3techs.com)

  • 웹에서 주소입력(https://w3techs.com/sites)
  • 브라우저 확장(FireFox, Chrome)

WebApplyzer (https://www.wappalyzer.com)

  • 웹에서 주소입력(https://www.wappalyzer.com/lookup)
  • 브라우저 확장(FireFox, Chrome, Edge)
  • Node 모듈

BuiltWith (https://builtwith.com)

  • 웹에서 직접사용 (https://builtwith.com)

isitwp (https://www.isitwp.com)

  • 웹에서 주소입력 (https://www.isitwp.com)

PageXray (https://pagexray.com)

  • 브라우저 확장 (Chrome)

Whatruns (https://www.whatruns.com)

  • 브라우저 확장 (Firefox,Chrome)

SimilarTech (https://www.similartech.com)

  • 웹에서 주소입력 (https://www.similartech.com)

FrontEnd개발 – Angular2 개발시작

node 기술혐오

node진영은 비슷한 기술이 너무 많아 선택장애가 생긴다.

angular, react, backbone, ember polymer

왓 시바 다섯개다.

https://gist.github.com/makmanalp/9b7f50aa16d21c2f9d37

당신이 ~~를 선택해야 하는 이유같은 글 많이 읽어봤는데 뭐 다 비슷했다.
결국, 구글과 TypeScript 때문에 Angular를 선택

(처음 나올때는 angularJS였는데 이제 TypeScript를 쓰고 앱을 만들때도 쓰기 때문일까…
영역을 확장하기 위해 Angular라고 이름이 바뀐 것 같다.)

Angular2 설치과정


npm -g install @angular/cli

이렇게 하면 설치가 된다고 하는데… 그리고 분명 되어야 하는데… 먼가 오류가 난다.
뭔가 이상했는데

node -v
0.xx

윈도우에서도 다시 설치하면서 찾아보니 2013년이었나..?
node 가 주력이 아닌 사람들은 다들 비슷한 상황일거다.

이거보고 삭제진행(Mac)
http://stackoverflow.com/questions/11177954/how-do-i-completely-uninstall-node-js-and-reinstall-from-beginning-mac-os-x

아래 명령 둘중에서 하나 실행시키면 되는데.. 오타나면 컴퓨터가 맛이갈수도 있겠다.

$ sudo rm -rf /usr/local/{lib/node{,/.npm,_modules},bin,share/man}/{npm*,node*,man1/node*}

$ sudo rm -rf /usr/local/bin/npm /usr/local/share/man/man1/node* /usr/local/lib/dtrace/node.d ~/.npm ~/.node-gyp /opt/local/bin/node opt/local/include/node /opt/local/lib/node_modules

한다음에 공식사이트에서 재설치했다.
https://nodejs.org

튜토리얼 진행

https://angular.io/docs/ts/latest/cli-quickstart.html


npm install -g @angular/cli

ng new my-app

angur2 기본프로젝트를 생성하고 나니….

의존성 관리를 npm으로 하고 karma라는게 깔린다.
빌드는 ng-cli가 하는 것 같고…

그리고 모르는게 추가돼있다.

karma, e2e ???

karma는 자바스크립트 테스트 러너 라고 한다
https://blog.outsider.ne.kr/1020

e2e도 유닛테스트 관련 프레임워크인 것 같다.

Anguar개발에 익숙해지고 최적환경을 구성하려면 시간이 좀 더 걸릴 듯 하다.

서버단이 아닌 프론트엔드 라이브러리가 npm에서 싸잡아 관리되는게 못마땅하니
Bower를 적용해야겠고
빌드도 일관성을 위해 gulp를 적용하는게 나을지 npm을 써야할지

며칠지나서 다시보니
bower는 Deprecated된 것 같다.
gulp, grunt도 대세에서 밀려난 것 같은데…
빌더가 아닌 Bundler라는 개념으로 webpack이 사용되고
의존성관리는 yarn과 npm으로 하고 있다.
yarn과 npm은 기능이 중복되는것같은데 왜 따로 있는건지

web.xml 버전별로 정리

를 하려고 했지만…. 최근것만

4.0

은 언제 나오나

 

3.1

 

3.0

 

JavaScript 주소 가져오기

Javascript에서 기본 오브젝트 정보를 가져올 때는 DOM구조를 타고 내려가는게 중요한데

 

location.href 라고 쓰는것은

window.document.location.href 와 동일하다.

 

요즘은 디버거가 잘 되어 있어서 location만 치면 객체구조를 확인가능하다.

 

Social 개발 – facebook 좋아요 버튼

<meta property=”og:title” content=”제목”/>
<meta property=”og:type” content=”article”/>
<meta property=”og:image” content=”http://image.server.com/image/path.jpg”>
<meta property=”og:site_name” content=”MemoBlog”/>
<meta property=”fb:app_id” content=”1304102″/>
<meta property=”og:url” content=”표시주소”/>
<meta property=”og:description” content=”description”/>
http://stackoverflow.com/questions/8217404/how-to-clear-facebook-like-button-cached-information
페이지가 변경되도 페이스북에 캐시가 남아서 제대로 동작하지 않는 경우에는 이 페이지에 접속해서 주소를 입력하고 새로고침을 해준다.
https://developers.facebook.com/tools/debug/og/object/
쉘명령으로 한꺼번에 처리할 때는

NextWebFramework 3. 뷰단의 구조

View단에서 사용가능한 REST Client.

Engine에서 DB2API가 자동으로 지원되게 하는 부분은 간단히 구현이 가능하다.
그렇다면…. thrift를 쓸까 어쩔까 하던… 웹/모바일/…등등등에서 이 API or RPC를 직접 호출하기 위한 방법…?

자바스크립트에서 간편하게 사용 가능한 REST Client가 존재한다면…?
이 부분을 Thrift에서 처리할 생각이었지만 더 간단한게 있다면… 적용할만하다는 생각이 들었다.

그리고 그 기반기술이 될만한것들…
https://github.com/garycourt/JSV
Json Validation라이브러리. 이거 조금 적용해서 도메인 구조를 json으로 정의하도록 만든다.
https://github.com/jashkenas/backbone/
js 모델 라이브러리
http://abaaso.com/
REST관련 라이브러리

프레임워크의 생산성 향상을 위해서는 전용 ide가 필수적인데… json기반으로 도메인을 정의한다면 웹쪽의 ide는 별도로 개발이 필요하지 않게 된다.

그래도 묶음배송기능, 로컬AJAX에서 외부 리소스호출을 위한(크로스도메인땜에) 인터페이스같은건 따로 개발이 필요하긴 하다.
좀 큰 부분은 해결된듯하다.
회사때리치는 일만 남았다.

NextWebFramework 1 : 무거운 프레임워크와 복잡한 테스트

요즘 웹 프로젝트는 사양이 상당히 좋은 컴퓨터로도 가동시키는데 30초? 조금 안좋은 컴퓨터로 하면 1~2분 무거운 프로젝트라면 5분까지 걸리기도 한다.

어마어마하다.

화면하나 고치고 테스트를 해보려면 5분을 기다려야 할 수도 있다. 동적으로 로딩이 되지만… 무거운 프로젝트라면 이조차도 버겁다. 로딩하다가 Pergem어쩌고 하면서 멈춰버린다. 그러면 재시작을 해줘야하니까….

그래서 사용하는게 Unit 테스트…. 그런데 View는 어쩔건가

별수없이 서버를 올려야된다.

아니면 가벼운구조로 새 프로젝트를 생성하고서 테스트를 하거나…  뭐 어쨌든 저쨌든 귀찮은 과정을 거쳐야만 한다.

자바는 너무 과도하게 무거워졌다. 루비도 몇번 돌려보긴 했는데 역시 마찬가지다. 서버 올리는데는 조금 시간이 걸린다. html테스트하는것처럼 바로바로 로딩이 되질 않는다.

이건 확실히 문제가 있다.

 

이 부분을 개선하기 위해서 필요한 것은 역시 모듈화.

그렇다면 어떤 구조로 나눌것인가가 문제가 된다.

 

1. SSO 를 중심으로 각 기능별로 웹사이트를 나눠버린다.

2. View / Controller / Service / Model / DB 의 방향으로 각 모듈별로 나눈다.

1번은 흔히 사용되는 방식으로 프로젝트의 크기를 적절히 분할한다면 효과적인 방법일 수 있다.

그런데 개인적으로 2번의 방법을 시도해보고싶었다. 이유는 간단하다. 2번이 더 간단하고 더 가볍고 효율적이다. 다만… 적절한 아키텍처가 제시되지 않고 있다. (찾아봤는데 없어서 없다고 단정지었다)

 

2번의 방법을 View-Engine-Model 구조로 정의한다.

VEM(가칭)

각 업무담당자별로 모듈을 나눌 수 있다는게 장점이다. 협업을 줄여서 각 모듈간의 충돌을 최소화한다.

설계단계는 별로바뀌는게 없을 것 같다. 기획이 나오고 개발자와 회의를 거쳐 구현이 가능한지를 결정한 다음 스토리보드를 뽑아낸다. 도메인모델과 디비도 이 단계에서 어느정도 설계가 될거고.

이 모델의 강점은 여기있다. 뷰단계에서 데이터가 들어있는 것처럼 화면을 동적으로 보여줄 수 있다는 점.

입력할 데이터를 미리 정의된 프로토콜형태로 text로 저장시켜놓은 후 화면단코드(자바스크립트,css등)을 수정하면서 바로바로 확인하며 코딩이 가능하다.

대략이런식으로 매핑이 되게 할 수 있다.

현재 나와있는 jquery , angular 등의 JS라이브러리로 구현이 가능할것으로 보인다. 이 부분은 조금 더 검토필요…. 화면단은 좀 덜해봐서

어쨌든 데이터를 기다리지 않고 화면단의 변경이 가능하다는 점이 가장 큰 장점이다. 일반 SI회사에서 가장 요구사항 변경이 잦고 고객사에서 귀찮게 하는 부분이 이 화면단인데 이 부분에 대해 초기대응이 가능하고 변경이 적어진다는 것이 장점이다.

보안이슈가 있는 경우에는 view쪽에서 사용자 인증 필터를 깔아야되는 경우도 있을 수 있다.(있을수도 있다가 아니라 대부분 경우-필요없는데서도- 이런 요청을 하지 않을까 싶다. 인증시스템은 기존에 만들던대로 만들면된다.)

 

View – Engine간의 연결

Ajax와 RPC.

언어에 따라 달라지겠지만 표준은 ajax와 rpc가 될 것이다. 화면과 로컬서버간에 ajax로 통신을 하고 ajax로 데이터를 가져오는 것은 cross domain제약이 있기 때문에 rpc를 이용해 통신을 하도록 한다. 쓰리프트의 경우 js도 지원을 하기 때문에 더 편리?하게 사용이 가능할지도 모르겠따. 생각해보니 쓰리프트 js거치는게 이것과 비슷하게 생성이 됏떤것같다.

앞의 화면코드에서 User배열을 json형태로 받았는데 이 부분은 다음과 같은 파라미터를 전송해서 호출한다.

묶음배송기능. ajax호출시 여러개의 데이터를 한꺼번에 호출하는 경우가 많은데 이 경우 RPC에 부하가 크기 때문에 묶음배송기능이 필요하다. 그래서 파라미터는 배열로 전송한다.

request : [{메서드명, 데이터(테이블 or 도메인)명}, {} …]

response : {{rpc상태메세지}, {data}, {data}}

response Set 첫번째 데이터는 상태메세지다. Set이지만 텍스트형태니까 앞쪽에 포함시키면 앞쪽이 된다.

각 domain이 가공되는 형태는 pre/post handler resolver 등을 붙여서 후처리 가공할 수 있도록 지원한다.

화면단에 보일 데이터의 형태인 도메인과 디비에 저장될 테이블은 같은 형태가 아닐 수 있다. 화면단에서는 완성된 vo를 호출하기 때문에 뷰에서 필요로 하는 데이터를 쿼리만 입력하면 완성된 데이터로 출력을 해 준다. 이 부분에 대해서는 api를 만들면서 만들어본적이 있으니 간단할듯 싶다.

 

Model : Engine부분과 굳이 분리할 필요는 없다. 합쳐지는게 더 효율적이지 않을까

ORM을 사용할 경우 Engine에 상당부분 포함될 수 있다.
ActiveRecord 생각하다보니 Rails구조가 떠올랐는데….
이 구조가 왠지 레일즈와 닮은것같다.

ORM을 써도 그냥 쿼리를 넣을 경우에는 그냥 쿼리로 뽑아볼수도 있어야한다.

 

이걸 분리시키면 너무 복잡하니 그냥 View-Engine Structure로 하는게 나을것같다.

구체적인 아키텍처는 다음번에 이어서.

JavaScript – 이벤트 발생후 화면 다시 로딩

그냥 이렇게 써놓으면 된다.

확인 후 재시작… ajax같은거 사용후에 적용해놓으면 좋다.

상황에 따라 재로딩을 하는 방식이 달라져야한다.

ajax로 추가되는 리스트인 경우는…. 다른방법인데 지금은 생각이 안난다.