Dev

왜 hapi를 고려해야하는 하는가? (번역)

December 2, 2018

왜 hapi를 고려해야하는 하는가? (번역)

일하고 있는 곳에서 hapi를 사용하고 있어 관련 글을 하나 번역해봅니다.

원글은 Why You Should Consider hapi입니다.


새로운 웹 애플리케이션을 시작할 때, 플랫폼을 처음 선택합니다.: node, Go, Rails 및 기타 등등. 두 번째 선택은 프레임워크입니다. node를 선택했다면, 선택할 수 있는 좋은 프레임워크가 많이 있습니다.

선택 목록의 상단에 hapi가 있어야 하는 이유가 있습니다.

node의 초기 시절부터, hapi는 엔터프라이즈급 솔루션이었습니다. 원래 월마트 블랙 프라이데이 규모를 지원하기 위해 개발되었습니다. 입증된 기록 덕분에 hapi는 명성을 유지했습니다. 아마도 hapi로 구현된 하나 이상의 웹 애플리케이션을 hapi로 구현된 지 모른 상태로 매일 사용하고 있을 수 있습니다.

품질

사실상 측정 가능한 모든 품질 지수에서 hapi는 최상위권 점수를 기록하고 있습니다.

코드 가독성

가장 중요한 품질 지수라고 생각하는 것부터 먼저 시작할 것입니다. – 코드 가독성. node 프레임워크를 선택하고 코드를 쉽게 따라갈 수 없다면, 빨간 신호입니다. 코드 가독성은 가장 중요한 항목과 직접 관련되어 있습니다.: 단순함, 보안, 유지 보수성

어떤 것이 잘못되었고 그 이유를 찾아야 할 때, 세상에서는 모든 차이가 나타납니다. 코드가 작업하기 쉽기 때문에 지난 몇 년간 찾았던 대부분 중요 이슈는 해결책으로 보고되었습니다. 가독성과 성능이 충돌할 때 항상 가독성을 선택합니다. 기계는 점점 빠르고 저렴해집니다. 사람은 더 느리고 더 비쌉니다.

코드는 불필요한 성능의 모든 비트까지 쥐어짜기 위해 최적화되지 않기 때문에, 변경은 복잡하고 거대한 해결법을 요구하지 않습니다. 복잡성을 피하는 것이 작성 또는 리뷰하는 모든 코드에서 스스로 반복하는 주문이기 때문에 hapi는 가장 빠른 프레임워크가 되지 않을 것입니다.

의존성

hapi는 외부 코드 의존성이 없는 최초의(그리고 여전히 유일한) 프레임워크였습니다. (mime 유형에 대한 정적 JSON 데이터에 대한 하나의 외부 의존성을 가지고 있습니다.) 소규모의 핵심 팀에서 모든 코드 의존성을 관리하고 제어합니다. 그리고 최종 통합 방법은 제가 제어합니다.

개인적으로 (수동으로) hapi에 들어가는 (node는 제외하고) 코드의 모든 줄을 리뷰합니다. 리드 관리자가 아니더라도 모든 의존성에 대한 모든 풀 리퀘스트를 리뷰합니다.

‘npm install hapi’ 실행하면, 설치되는 모든 코드는 검증된 것들입니다. 엉망으로 관리되는 (또는 모르는 또는 불확실한 개인에게 넘겨진) 깊은 의존성에 걱정하지 않아도 됩니다.

최근 소식을 지켜봤다면, 이는 큰일입니다.

코드 커버리지와 스타일

hapi는 100% 코드 커버리지를 요구하는 첫 node 프로젝트였습니다. 기존에 있던 코드 커버러지 도구는 충분하지 않아 직접 만들었습니다. CI에서 강요되는 엄격한 코딩 스타일을 정의한 첫 번째 사람들 중 하나였습니다. 새롭고 더 좋은 접근법이 개발됨에 따라 스타일을 재검토하고 전체 코드 베이스를 새로운 표준으로 주도적으로 옮겼습니다.

열 이슈

전체 프레임워크는 27개의 모듈로 구성됩니다. 자체 (유효성 검사) 프레임워크인 joi를 (그리고 정적 데이터 파일인 mime-db) 제외한 나머지 모듈들 전체는 6개의 풀 리퀘스트 요청, 9개의 보고된 이슈 그리고 19개의 기능 요청 또는 질문이 있습니다.

이는 놀랄 만치 적은 숫자들입니다, 특히 hapi는 월 평균 130만 다운로드가 넘는 두 번째로 가장 많이 사용되는 node 프레임워크로 평가되기 때문입니다. 다른 소수의 프로젝트에서만 그렇게 적은 수의 열린 이슈를 관리하고 있습니다. 이는 쉽지 않습니다. – 이를 달성하려면 충분한 노력이 필요합니다.

보안

공동 저술한 OAuth 스펙의 최종 결과에 감동하지 않을 수 있지만, hapi를 가장 엄격한 보안 우선 접근으로 만들었다고 확신합니다. 오늘날까지 앞에 있는 것을 주장할 수 있는 유일한 프레임워크입니다. hapi에서 보안은 사후점검 또는 추가 기능이 될 수 없습니다. 이는 우리가 하는 모든 방식의 핵심입니다.

코드 위생(Code Hygiene)

코드가 관리, 제어, 배포되는 방법에서 항상 가능한 가장 안전한 방법을 선택합니다. 모든 기여자는 GitHub과 npm에서 2FA를 활성화해야 합니다. 모든 발행은 2FA를 사용해야 합니다. 핵심 프레임워크에는 모든 의존성의 무결성 해시값을 명시한 shrinkwrap 파일이 있습니다. 그리고 곧 GitHub의 코드가 npm 패키지와 일치하는지 확인하는 과정을 자동화할 것입니다.

보안 기본값

모든 기본값은 가능한 항상 가장 안전한 옵션입니다. hapi는 메모리 누수 정보 또는 다양한 수준에서 악용될 수 있는 에러 메시지를 차단합니다. 서버 로드는 기본으로 페이로드 제한과 요청 제한 시간 초과로 보호됩니다. 그리고 더 많은 표준이 가능하게 되면, 새로운 보안 헤더가 코어 프레임워크에 추가될 것입니다.

통합 구조(Integrated Architecture)

애플리케이션 측면에서 hapi는 node 프레임워크에서 가능한 가장 포괄적인 권한과 인증 API를 제공합니다. 요청 인증은 요청 생애 주기에서 핵심적인 부분이며 사용자가 (올바른 위치와 순서에 따라 바르게) 던지는 미들웨어가 아닙니다.

그리고 우리의 초보안 의식 때문에 hapi는 암호화되고 서명된 쿠키 및 비밀(secret) 또는 키 순환 같은 향상된 기능을 제공합니다. 안전하지 않은 애플리케이션을 만드는 것에 대한 가능한 변명은 없습니다.

개발자 우선

모든 hapi 기능은 애플리케이션 개발자를 염두에 두고 만들어졌습니다. 새로운 기능을 추가할 때, 항상 더 또는 덜 직관적으로 만드는 것인지 스스로 묻습니다. 마지막으로 hapi 사용자와 이야기할 때 가장 궁금해하는 것은 “행복하십니까?”입니다.

모든 사람이 결정한 모든 선택을 동의하지는 않을 것이며 웹 애플리케이션을 만드는데 다른 여러 가지 가능한 접근들이 있습니다. 그러나 hapi에 투자한 누군가가 그 결정을 뒤에 후회하는 경우는 좀처럼 없습니다. 저는 계속 묻습니다.

설문 조사 이후 설문에서, hapi 개발자는 만족도에서 매우 상위에 있습니다. 이에 대해 자랑해도 괜찮은 하나의 척도입니다.

예측 가능성

Express를 사용하는 것 대신 hapi를 만드는 주요 이유 중의 하나는 예측 가능성이 완전히 부족하다는 것입니다. 경로(route), 미들웨어 또는 서버 수준 메소드를 추가하는 순서는 결과를 좌우하고 종종 숨겨진 부작용이 나타납니다. 프로젝트가 커짐에 따라, 미들웨어가 다른 미들웨어를 넘어서거나 또는 존재하는 경로에 대한 경로 패턴을 덮어쓸 때 일상적으로 문제가 발생했습니다.

hapi는 강력한 보장을 제공하는 첫 node 프레임워크이고 큰 분산된 팀이 공통 코드 기반으로 함께 작업할 수 있게 합니다.

다른 플러그인을 요구하는 플러그인을 로드한다면 명시적으로 지정할 수 있습니다. 확장 지점을 추가한다면 미래의 확장이 기존 균형을 방해하지 않게 상대적인 순서를 지정할 수 있습니다. 경로 패스는 절 충돌하지 않을 것이고 추가된 순서가 아닌 항상 같은 우선순위에 따라 결과를 낼 것입니다.

확장성과 사용자화

hapi는 사실상 node 프레임워크 플러그인, 요청 생애 주기, 서버 메소드 그리고 사용자 확장을 만들었습니다. 인증, 권한 처리 그리고 유효성 검사를 포함한 모든 단계에서 가장 성숙하고 완전한 확장 지점 세트를 가지고 있습니다. 프레임워크 주변을 각자의 방법으로 해킹하지 않아도 되며 내부는 수수께끼가 아닙니다. 모든 단계는 명확하게 문서로 만들 져 있습니다.

hapi에서 모든 것은 확장을 안전하고 쉽게 사용할 수 있게 적절하게 이름 지어져 있습니다. 두 개의 확장 또는 플러그인이 실행시간에 충돌로 제품화 단계에서 애플리케이션이 실패할 걱정할 필요가 없습니다. 모든 것은 개발 중 쉬운 충돌 식별로 로드 시에 검증됩니다.

나머지

이것들은 단지 하이라이트입니다. 설정 중심 접근에 대한 것은 이야기하지 않았습니다. 내부와 외부 내장 유효성 검사. 캐싱 지원. 풍부한 플러그인 생태계. 가장 최신 JS 언어 기능 사용…

그러나 저는 hapi 커뮤니티에 큰 소리로 말하고 싶습니다. 저는 더 좋고 더 많은 지지와 보호받는 사람의 그룹의 일부인 적이 없었습니다. GitHub에서 질문에 대답하는 것에서 Slack에서 도움을 제공하는 것까지 hapi 커뮤니티에는 가장 훌륭하고 똑똑한 친구들이 주변에 있습니다.

그래서 다음 node 프로젝트를 위해서 hapi를 살펴보세요. hapi를 좋아하게 되리라 생각합니다.

왜 hapi를 고려해야하는 하는가? (번역) was originally published by developer at SoftDevStory Blog on December 02, 2018.