RecoPick



'Express'에 해당되는 글 1건

  1. 2014.10.30 Hapi.js로 Node.js를 시작하세요. - 1부 Why Hapi.js

안녕하세요. 이번에 Recopick팀에 새로 합류하게 된 정재훈이라고 합니다.

먼저 간단히 제 소개를 드리면, 저는 Recopick팀에서 메인업무로 기획을 맡고 있으며 부 업무로 UX 디자인을 진행하고 있습니다. 

는 훼이크! 닥치는 대로 뭐든 하는 개발자 입니다. (a.k.a 닥치고 시키는대로하는 개발자) 

네, 하루살이 처럼 오늘 만을 살아가는 개발자입니다. (내일이 안 보여요..) 

팀 합류 전에는 iOS 클라이언트 개발을 주로 했었구요.(깃헙 팔로우 하기)  백엔드 개발도 잠깐 했었는데 Ruby on Rails을 이용 했었습니다.

지금은 노드로 이동했습니다. 하하하하하하하하하하하…. 죄송합니다. ㅡ,.ㅡ; 이동 후 멘탈에....



몇 줄 안 썼는데 벌서 피로감이 몰려 오네요. 나머지는 다음주에 쓰고싶네요. 그럼 짜이지엔 쒜쒜.



도 훼이크… 추억돋는 짤을 사용해보고 싶었어요.

이제부터 정말로 Hapi.js에 대해 설명 드리도록 하겠습니다.  

1. Hapi.js 란 무엇인가?

Hapi (HTTP API server)는 WalmartLabs에서 월마트 모바일 플랫폼에 사용하기 위해 만들었습니다. 리드개발자는 OAuth 리드 개발자로 잘 알려진 Eran Hammer 입니다.
이름 그대로 API Server 특히 모바일을 위한 서버 개발에 좋은 기능들을 많이 담고 있습니다. 내 대세는 모바일.. 물론 일반 웹서버 개발에도 전혀 불편함이 없습니다. 이후에 차차 설명드리겠습니다만. 다양한 기능들을 지원합니다. Batch Request, Pack, Pre, Plugin등이 Core 개발 시에 고려되어 굉장히 효율적으로 동작합니다. 

Hapi 탄생배경
개발팀은 월마트 모바일 개발을 위해 요구사항이 정해져 있었고 요구사항을 충족시키는 프레임워크를 개발해야 되었습니다. 처음 개발 시에는 Express framework를 기반으로 하피 개발을 시작했으나 몇가지 난관에 봉착하게 됩니다. 우선 mobile을 위해 batch functionality를 추가하다 express는 http server와 router 가 밀접하게 연결 되어 있어 효율적으로 기능을 추가 못하는 상황에 봉착합니다. 또한 너무 많은 미들웨어들이 connect roots(req,res,next)에 들어가 있어서 디버깅이 쉽지 않았다고 합니다. 
간단히 요약해드리면 쉽게 가려고 Express에 Wrapping하려다 망테크 한번 타고 분노를 Express 단점에 두고 맨탈 다잡고 Express의 문제점을 수정하는 방식으로 새로 만들게 되었다는 그런 스토리입니다.~ (물론 자신들이 원하는 프레임워크 요구사항 안에서의 문제 입니다) 자세한 내용은 여기 참조 

이후에 자세히 설명 드리겠지만 위에 탄생 배경으로 부터 유추해 볼 수 있는 Hapi의 장점은 아래와 같습니다.
1. Http Server 와 Router의 분리.
2. 심플한 Core (기본 미들웨어의 이해 없이는 깊이 있는 디버깅이 힘든 것과는 다르다)
3. 비즈니스 로직과 트랜스포트 레이어의 분리. 

물론 Express에서도 노력하면 비즈니스 레이어와 트랜스포트를 분리는 할 수 있겠지요. 그러나 비즈니스 로직은 사업이 변경 됨에 따라 자주 변경될 것이고 시간에 쫒기다 보면 분리에 대한 생각은 우선순위에서 밀리게 되겠지요. 하지만 Hapi 처럼 프레임워크 상에 구조적으로 분리를 강요한다면 비즈니스 로직이 자주 수정 되어도 Isolation을 지킬 수 있겠지요. 

저도 저자 처럼. 프레임워크 상에서 구조적 분리를 강요하는 것이 옳다고 생각합니다. 이게 프레임워크 철학인 것이죠. 또 다른 Hapi.js 장점은 이해하기 쉬운 심플한 Core와 필요한 플러그인들만 붙여쓸 수 있도록 완벽히 분리된 모듈들입니다. 

하피는 안전성이 검증된 오픈소스 프레임워크 입니다.
 모질라, 야후, 페이팔, Beats Audio, npmjs.org, 디즈니등에서 사용되어 지고 있으며 계속해서 발전해 나가고 있습니다.
 
Hapi는 프레임워크 컨셉이 명확합니다. 
1. configuration-centric design framework
2. Business Logic 과 transport layer의 분리 
3. Plugin Architecutre 와 Pack을 통한 모듈화.
4. native node의 장점을 유지 . (buffer ,stream)

많은 회사들이 (Express 말고) Hapi를 선택했습니다. 또는 전환 했습니다. (여기)
엄청난 User Pool을 가진 Express를 두고 왜 많은 회사들이 Hapi.js를 사용할까요? 

2. Why Hapi.js ?


"ㅇㅇ Hapi 좋은거 알겠어 근데 Express.js가 기능은 더 많은데  왜 Hapi를 써야되지?”

일단. 둘간의 비교를 하기 전에 NPM의 경우 왜 Hapi를 선택했는지 알아보고 다시 돌아오겠습니다.

NPM은 새로운 웹사이트를 구축하기 전에 프레임워크를 조사했습니다. 

프레임워크 선정 기준은 아래와 같았다고 합니다. 
1. 모듈화
2. 간결하고 기능 추가가 쉬울 것
3. 쉽고 빠르게 컨트리뷰터들이 적응하고 개발할 수 있을 것 ( 협업이 쉬운 프레임워크)
4. 템플릿 엔진
5. 그외 (안전성, 보안, 생산성, 지원)
그외 다른 조건으로는 개발기간은 1주일 정도 였다고 합니다.

조사 결과.
Restify - 템플릿엔진 없음 ,  Sails - 너무 기능이 많음  , KoaJS - generators를 쓴것은 맘에 들지만 아직 프로덕션레벨 사용가능 의문? 
-> Express or Hapi

NPM이 Hapi.js를 선정한 이유.
1. hapi plugin을 이용한다면 각 모듈 서비스를 별로 분리 개발이 가능하여 나중에 각각 별도의 서비스화가 가능하다. Express라면 별도의 모듈화 과정이 필요하다.
2. 성능. Walmartlabs는 Node.js Core Memory Leak을 발견하고 해결한 팀입니다. 이 팀이 Benchmark Drive Development를 기반으로 하피를 개발했고 결과적으로 성능 또한 훌륭하다고 합니다. 그렇겠지요 월마트 모바일에 쓸려면 성능은 중요하겠지요. 저 같은 중생은 믿고 쓰는거지요. 
3. 신뢰성,안전성 (Core 부분 Coverage 100%)
4. 빠른 이슈해결. (hapi 개발팀의 대응이 빠릿했데요.)

제가 보기에는 2,3,4 항목 보다는 1번 모듈화가 쉽다는 점이 NPM이 Express.js 대신 hapi.js를 선정한 가장 큰 이유 일 것 같습니다.

그외의 Hapi.js의 우수성.
1. Plugin Architecture
2. 훌륭한 기본 플러그인 Validation(joi) login(bell)….


3. Hapi vs Express 


Express.js의 문제점
1) http server와 router가 밀접하게 연결되어 있다.  
2) 여러가지 미들웨어들이 내부에 존재. : 너무 많은 서드파티 미들웨어를 가져오다 보니 해당 미들웨어 대한 공부 없이는 전체를 이해하기가 너무 어렵다. 디버깅은 헬게이트 안그래도 요상한 에러가 잘나는 Node.js에 충격과 공포!
3) 철학이 없다. 이것 저것 모든지 다 있는 만물상이 되어버렸다. 



Express.js와 비교하여 Hapi.js가 가진 장점
1) '프레임워크의 철학이 개발프로세스와 코딩스타일에 영향을 미친다’  - Plugin 시스템을 통해 Core는 깔끔한 상태로 유지하며 모듈화를 통해 다양성을 충족하는 방향을 잡았다.
2) Business Logic과 Transport Layer의 분리와 Plugin을 통한 모듈화를 통해 대형프로젝트에 협업하기 좋은 구조를 프레임워크에 녹여 내었다.
3) 코드를 깨끗하고 간결하게 관리 할 수 있다.

Express.js와 비교하여 Hapi.js가 가진 단점.
1) 커뮤니티 베이스가 상대적으로 작다
2) User Pool이 상대적으로 작다.


Merge Conflict 따위 일상이야! , 자바스크립트에 뭔 Configuration Centric이야 하시는 분들은 Express 계속 쓰시면 되구요.

코드보다는 설정 중심이 가독성이 좋고 깔끔하거든!, 이제 Node.js 협업이 중심이야. 모듈화 깔끔하게 되면 좋지 않니? 하시는 분들은 


저와 함께 Hapi를 사용 해보시면 되겠습니다. 실제로 홈피의 Tutorial 내용이 Core의 대부분이구요 10~20분 정도면 금방 익힐 수 있습니다. 

그리고 현재 Hapi.js의 커뮤니티 베이스도 지속적으로 증가할 것 같습니다. 그 이유는 반사이익 때문인데요.. 자세한 것은 다음장에서 설명드리겠습니다.

4. 어두운 그림자가 드리운 Express.js 

Express에 대해 모두가 우려하는 사항에 대해 객관적으로 말씀 드리겠습니다.

1) 떠나간 메인 개발자 TJ - Farewell Node.js
노드의 콜백지옥에 흥미를 잃고(?) Go로 떠나시면서 Express.js 메인테이너를 모집하게 됩니다. 꽤 유명한 사건이라 길게 설명을 하지 않겠습니다. (자세한 사항은 윗링크 참조)

2) Strongloop에 넘어간 Express와 떠나가는 Contributor들
메인테이너 권한을 팔았다? Express 리포는 TJ에서 Strongloop라는 스타트업 회사에 넘어갔습니다. Strongloop는 Express의 메인테이너가 되며 엄청난 홍보효과를 누렸지요.
물론 TJ가 팔았다는 증거는 없습니다. 정황 상… 여러사람들이 의심하고 있습니다.
여러사람들이 정황상 팔렸다고 생각하는 가장 큰이유는  Exppress.js foundation에 Repo로 넘기면 되었을 텐데…그렇게 하기로 했었구…

하여튼 Express 판매와 관련하여 3 개월전 Express.js Repo에서는 '왔다 장보리' 급의 막장드라마가 펼쳐졌었죠

참고 Open Source Dickishness by Eran Hammer

야! 싸움구경 났데~ Maintainer가 바뀐날 Github repo issue 



TJ의 반박글 StrongLoop & Express 

[첨부] 지난 12개월 동안 Commit 수를 보면 왜 Douglas가 TJ에게 분노했는가를 알수 있습니다
303  Douglas Christopher Wilson
 84  Jonathan Ong
 66  Roman Shtylman
 49  TJ Holowaychuk
  5  Fernando Silveira

저는 TJ가 한말 중에 '대부분의 상업적 지원을 받은 오픈소스 프로젝트는 죽거나 망했다'는 내용이 와닿네요. 

왜~ 슬픈 예감은 틀린적이 없나~~~

'I completely understand the rage that I'm seeing from everyone, it's easy to assume every commercial sponsorship will lead to the death of a project or poor results, but I'm sure we can all list numerous cases where the opposite is also true. I think it still takes a community to hold it together regardless.’ 

물론 현재까지 만으로도 Express는 훌륭한 프레임워크입니다. 하지만 많은 컨트리뷰터들이 이탈한 것은 자명한 사실이고 앞으로는 StrongLoop가 리드 메인테이너로서 자신들이 방향을 정하고 진행되어가겠죠. 상업적 기업이 활용하는 프레임워크인 이상 오픈소스라도 자신들의 방향에 맞춰지게 되지 않을까 싶습니다. 또한 상업적인 용도로 쓰일 프레임워크에 무료로 공헌하는 개발자는 없겠지요. 

물론 시간이 지나봐야 알겠지만 좋은 컨트리뷰터들이 계속해서 떠나간다면 익스프레스의 미래는 어둡다고 생각되어집니다.

이런 상황이라면 Sail.js 같이 Express Foundation 위에 만들어진 Framework들은 빠른 시일 내에 koa로 갈아타지 않을 까 싶습니다. 

여러가지 미련을 남겨둔채 여기서 1부 Why Hapi.js를 마치겠습니다.





다음 2부에서는 Hapi.js Restful Service 개발에 대해서 알아보겠습니다.


Posted by recopick