Web 개발 용도별 기술선택

간단하게 만들려면 js, python이 좋다??

로그인, 디비 정도만 딱 붙이고 추가기능이 전혀 없을 경우….

보안이나 벨리데이션 신경쓰지 않고 프로토타이핑을 하는 경우에 한해서는

js, py가 괜찮은 선택이다

완성된 프레임워크 Spring, RoR

조금 제대로된 뭔가를 만들려면 이런걸 쓸 수 밖에 없다.

python으로 뭐 하려면 멀티스레드 지원 때문에 엄청 불편하다

모든걸 편법으로 처리해야 하는데 Queue, multiprocess, Celery 등등.. 이것저것 하다보면

전혀 간단하지가 않다

메시지 기반 Akka 프레임워크

게시판 종류의 서비스 말고 좀 복잡한 서비스 만들 때 … 필요하다.
거래소, 쇼핑몰 등 실시간, 비동기성이 좀 필요한 경우

Storm, Flink, Kafka, Kafka Streams 정도는 써 봤는데

Flink, Storm은 지들이 알아서 분산형 데몬을 관리 해 줘야 할 것 같은데… 그런부분에서 상당히 기능이 부족하다. 디버깅도 힘들고…유닛테스트도 힘들다. 분산형 키값공유 aggregate가 될 줄 알았는데…. 안된다. kafka와 효율면에서 뛰어나지 않다. 별 수 없겟지.. scale out을 할 때 kafka보다 더 이상 효율적이기는 힘들 것 같기는 하다.

이런저런 이유로 복잡도를 털어내고 사용하려면
kafka streams를 docker 환경에서 배포하는게 더 괜찮은데…
메시지 처리나 시리얼라이저 등등 여러부분을 직접 관리 해 줘야하는게 문제다.
그럼에도 불구하고… 나쁘진 않다.
여러 언어 지원 안되는게 조금 약점..이라고 할 수도 있지만 잡언어 안쓰면 되지

elixir도 akka처럼 액터기반 프레임웤인데 언어가 생소하니 접근성이 떨어지고 만들어놔도 인력 구하기도 힘든 문제가…

Akka로 이런 부족함을 채울 수 있을지 모르겠다

-테스트 더 해서 추가-

State Machine libray

상태관리

프로그램을 만들다 보면 상태가 중요한 요소일 경우가 많은데
회원의 상태, 프롯스의 상태
상태를 변경하기 위한 동작들
기존 상태 메모리에 로드, 디스크 저장 등등

별도로 관리하지 않고 디비에서 가져와서 한개씩 처리하면서 트랜잭션 거는거도 가능하지만
실수가 잦다

그래서 하나 만들어볼까 하다가 찾아보니 잔뜩 나와서 일단 정리

REF

  • https://statecharts.github.io/
  • https://kentcdodds.com/blog/implementing-a-simple-state-machine-library-in-javascript
  • https://github.com/davidkpiano/xstate
  • https://github.com/Ankzz/easyfsm/
  • https://github.com/hekailiang/squirrel

RubyOnRails 회원/권한 관리 Framework 목록

회원관리 솔루션

Devise

제일 많이 사용되는 솔루션. 특별한 이유가 없다면 이걸 쓰면 된다.
https://github.com/heartcombo/devise

Clearance

https://github.com/thoughtbot/clearance

CanCan

더 이상 업데이트가 되지 않고 있다.
https://github.com/ryanb/cancan

CanCanCan

Devise에 비하면 Star도 적고 특별히 차별화 되어있지 않다. Devise가 질렸다면 써볼수도 있겠지만…

권한관리 솔루션

PunchIt

Authlogic

https://github.com/binarylogic/authlogic
가장 최근 생긴 프로젝트로 업데이트 잘 되고 있는 것 같다

스파크 – 새로운 자바 웹 프레임워크

http://sparkjava.com/

스프링의 어노테이션 범벅 구조에 좀 질려있는 상황에서

간단히 메서드 체인 형태로 구성할 수 있는 프레임워크가 나와서 조금 반갑다.

그레일즈와 비슷한 구조?

다른건 제대로 써본게 없어서 정확히 비교를 못 하겠다.

아직은 초기라서 많은 기능지원이 없을 것 같다. 직접구현해도 나쁠것은 없지만….

회사일을 하다보면 그게 쉽지 않으니

추가적인 것은 나중에 확인.

2014 Web UI(JS,CSS) 프레임워크Framework & 라이브러리Library

최근 트렌드로 제시되고 있는놈들하고 기존 사용되던놈들…
여기없거나 설명이 매우 적은것들은 아주최신이라 서비스로 쓰기 좀 안좋을정도거나
오래되서 사용하지않는것들일 가능성이 높음.

PrimeFaces
게시판이나 이런거 등등 다양한 UI제공

Homepage

ICEFaces
PRIME이랑 비슷한것?
http://www.icesoft.org/java/projects/ICEfaces/overview.jsf

RichFaces
Prime이랑 비슷한것역시..
http://www.jboss.org/richfaces

jQuery thermeroller
아코디언모양 메뉴
http://jqueryui.com/themeroller/

960-Grid-System
twitter 직원이 만든듯 싶다. 포토샵이랑 fireworkd에 설치해서 쓰는 템플릿?
대강 이렇게 만들어놓은건 파이어웍스에서 CSS를 자동생성해주는 기능이 아닐까 하는 느낌
http://code.tutsplus.com/tutorials/which-css-grid-framework-should-you-use-for-web-design–net-25
http://960.gs/

AngularJS
구글에서 나온 JS프레임워크
http://angularjs.org/
지원사이트 : http://angular-ui.github.io/
모듈모음 : http://ngmodules.org/
예제 : https://github.com/angular/angular.js/wiki/JsFiddle-Examples
Bootstrap연동 : http://angular-ui.github.io/
Tstacular JS 테스팅프레임웍 : http://testacular.github.io/
AngularJS 팁 : http://deansofer.com/posts/view/14/AngularJs-Tips-and-Tricks-UPDATED
한국유저그룹 : http://angularjs.co.kr/
페이스북그룹 : https://www.facebook.com/login.php?next=https%3A%2F%2Fwww.facebook.com%2Fgroups%2FKorea.AngularJS.User.Group%2F

Backbone.js
https://github.com/jeromegn/Backbone.localStorage
언더스코어 : http://underscorejs.org/
튜토리얼 : http://backbonetutorials.com/
관계형모델 : http://backbonerelational.org/
페이징 : https://github.com/backbone-paginator/backbone-pageable
폼생성 : https://github.com/powmedia/backbone-forms
Mustache템플릿엔진 : http://mustache.github.io/
Bootstrap연동GRID : http://direct-fuel-injection.github.io/bbGrid/
Backbone.js기반 프로젝트 시드 : https://github.com/backbone-boilerplate/backbone-boilerplate
Backbone.js기반 MVC프레임웍 : http://chaplinjs.org/

Prototype

jQuery
다른것들 쓰는데 jQuery만 빼놓을수 없어서…
UI : https://jqueryui.com/
kendoui라던가 뭐 이래저래 jquery기반으로 만들어진 유료라이브러리도 꽤 된다. 역사도 오래되서 버그도 많이없고… 또 익숙하고. SI에 특히 유용.(유지보수관점)

Bootstrap
요즘 거의 대세인 웹디자인 템플릿
http://getbootstrap.com/
템플릿 : https://wrapbootstrap.com/
예제제작도구 : http://bootsnipp.com/
한글사이트 : http://webdesigncss3.com/bootstrap/
적용사례 : http://builtwithbootstrap.com/
테마 : https://wrapbootstrap.com/
테마 : http://www.templatemonster.com/properties/features/bootstrap-templates/
테마 : http://themeforest.net/search?term=bootstrap
테마제작도구 : http://stylebootstrap.info/

blueprint
CSS프레임워크
http://blueprintcss.org/

Foundation
http://foundation.zurb.com

Skeleton
http://getskeleton.com

HTML KickStart
http://99lime.com

HTML5 BoilerPlate
http://html5boilerplate.com

Initializr
http://www.initializr.com

GLYPHICONS
아이콘 사이트.유료무료
http://glyphicons.com/
http://glyphicons.getbootstrap.com/

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

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