Category Archives: 기획

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 2 : 다언어 모듈분산형 웹개발 프레임워크

프레임워크라는 말이 어울리나.. 아키텍처라고 해야할까

장점 : 멀티플랫폼 개발시, 다양한 언어로 대규모서비스 개발시, 병렬확장구조 개발시

단점 : 성가실수있다

– 필요한것

1. 각 모듈간 호환되는 도메인 정의가 필요하다. 예를들자면… Avro? 그런데 Avro도 이종언어간 통신시에 문제가 발생하는 경우가 있다. avro생성기는 Python의 숫자형을 Java의 Int형으로 변환을 시키는데 이 경우 자릿수가 달라서 Python->Java 방향으로 전송시 오류가 발생한다.

2. Model부분 간소화. rails와 같은 getUserByUsername, getUserByAddress같은 명령이 자동으로 생성되야한다. 자동이 안되는 부분은 model에서 수동으로 처리해야하니까….
ORM의 경우 rails처럼 자동으로 메서드 생성이 안되기도 하고 명확한게 좋기도 하고 자바에 다들 익숙하기도 하니까…. selectQuery(table(by(columns…), joinColumns(…)) …)같은 형태면 어떨까 싶다. V-E-M 구조를 사용할 경우 View설계와 함께 도메인 설계 다음에 테이블 설계가 먼저 이뤄진 상태일테니….
QUERY의 경우 select * from Users u, Board b where u.id = b.user_id; 와 같은 쿼리를 넣고 이름을 정하면 이 요청에 대한 응답은 자동생성….이 되야하는데 데이터 타입이 애매하니 avro나 각 언어 코드로 도메인을 같이 설정해줘야할것같다. 구현은 mybatis를 사용하면 간단. 다른 언어의 경우에는 비슷한 방법을 찾아보도록 해야겠다. 조인데이터의 경우에는 insert, update는 지원되지않고 각 테이블별로 자동으로 생성되는 insert,update코드를 사용하도록 한다.

3. Engine은 MVC모델에서 Service단 역할을 하는데 이 경우 Model의 데이터를 Direct로 필요로 하는 경우가 많다. 이런 처리를 위해서는 pass 자동화 필요. pass의 경우에는 Engine을 거치지 않고 Model로 요청. 각 테이블이 MQ의 채널이 된다면 Engine으로 매핑된 테이블과 엔진으로 매핑된 테이블을 분리시킬 수 있다.

4. Engine부분이 분리되어있기 때문에 View에서 Cross도메인 제약때문에 js만가지고 코딩을 하기는 힘들다. View와 함께 있는 php코드라면 요청 라이브러리를 지원해서 메서드를 호출하게 해서 직접 호출하고, java의 경우에는 controler를 자동으로 생성해주도록 한다. thrift에서 이 부분이 자동화되던데… 좀 고려해봐야겠다.

5. 각 모듈간의 보안..MQ를 쓰는 경우 여기 의존하도록 한다. 직접 통신하는 경우에는 … 설정값 중앙화 라이브러리를 추가로 만들어야하지 않을까…?

6. 모듈분리로 인해 통신포인트가 많아져 속도상에 문제가 발생할 가능성…
있긴한데… 클까? WAS-DB(1개)에서 View-MQ-Engine-MQ-Model-DB(5개)로 늘어난다.
요즘 웹페이지가 예전처럼 단일호스트단일페이지가 아니라 로그인하고 화면을 보여주는데도 리소스서버WAS인증서버등등을 거치게 되는것을 고려한다면 뭐 별로 커지는건 아닐지도 모르겠다. 다중 ajax요청을 묶음배송기능을 추가한다면 이 부분을 커버가능하겠다. 그런데 ajax묶음배송기능을 그냥웹에서도 쓰게될텐데…..

 

만들것 :

ajax묶음배송기능.

ajax용 controller 자동생성기능. javascript에서 도메인 설정을 해놓으면 거기에 맞게 자동으로 처리되도록… thrift 사용을 심각하게 고려.

Model자동화기능. 테이블을 스캔해서 domain파일을 자동생성해주는 기능은 필수. 만들어본적은 있는데… 디비마다 값이 다를 수 있어서 내가 쓰는 디비만 만들고 나머지는 설정파일을 추가해서 사용하도록 변경필요.

 

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로 하는게 나을것같다.

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

lombok project 개선안

테클이라면 테클이고 개선안이라면 개선안인 내용.

1. lombok limiter – 겟셋기에 자동으로 값 검증 추가

대강 이런형탤 생각하고 있다.

validation인데 코드 자동생성형식…

 

다른것도 몇가지 더 생각한거 있었는데….

2. 커스텀 Annotation 지원

상속받는 구조라던가…@Custom, @ToString

 

3. …..