Meteor 애플리케이션의 프로젝트 구조 개선을 위한 개발자 가이드

지난 몇 년 동안 사용 가능한 JavaScript 프레임워크의 수가 급격히 증가했습니다. 검증된 AngularJS부터 매달 나오는 프레임워크 점수에 이르기까지 선택할 수 있는 인상적인 다양성이 있습니다. 몇 년 전에 내 관심을 끈 것은 Meteor라는 프레임워크입니다. 대부분의 프레임워크와 달리 Meteor는 JavaScript 앱 개발을 위한 완전한 플랫폼을 목표로 합니다. Meteor를 처음 접하는 분들은 웹사이트에서 확인하시기 바랍니다. 이 기사는 Meteor에 대한 소개가 아닙니다. 대신 Meteor 프로젝트에서 구조를 도입하는 몇 가지 간단한 방법을 탐구할 것입니다.

Meteor의 가장 큰 장점 중 하나는 복잡한 JavaScript 애플리케이션을 신속하게 프로토타이핑하는 것이 매우 쉽다는 것입니다. Meteor는 MongoDB(통합 솔루션)와 상호 작용하는 노드 기반 서버와 결합된 프론트 엔드 템플릿 및 렌더링의 하이브리드이기 때문에 전체 스택 웹 앱 생성에 필요한 대부분의 초기 설정이 이미 완료되었습니다. 그러나 이것이 제공하는 개발 용이성은 함정이 될 수 있습니다. Meteor 앱을 빌드할 때 나쁜 습관에 빠지고 구조화되지 않은 코드가 뒤죽박죽이 되기 쉽습니다. 이것을 피할 수 있는 방법에 대한 몇 가지 제안이 있습니다.

스캐폴딩: Meteor의 관리 가능한 디렉토리 계층

첫째, 애플리케이션을 구축할 때 권장되는 폴더 구조를 유지하는 것이 중요합니다. Meteor를 사용하면 기본적으로 프로젝트 폴더 내의 아무 곳에나 파일을 배치할 수 있습니다. 원하는 경우 단일 파일에 모든 코드를 포함할 수도 있습니다. 이것이 해커톤 프로젝트에서는 효과가 있을 수 있지만 일반적인 프로덕션 수준의 확장 가능한 앱에서 발생하는 복잡성은 건전한 구조 없이는 관리하기 어렵습니다.

이 문제를 해결하기 위해 Chris Mather의 npm package iron을 확인하는 것이 좋습니다. 패키지에는 다양한 구성 옵션이 있으므로 여기에서 설명하기 어렵지만 일반적으로 다음과 같은 프로젝트 구조를 구성합니다.

 my-app/ |- .iron/ |- config.json |- bin/ |- build/ |- config/ |- development/ |- env.sh |- settings.json |- app/ |- client/ |- collections/ |- lib/ |- stylesheets/ |- templates/ |- head.html |- lib/ |- collections/ |- controllers/ |- methods.js |- routes.js |- packages/ |- private/ |- public/ |- server/ |- collections/ |- lib |- methods.js |- publish.js |- bootstrap.js

그러나 일부 프로젝트의 경우 이와 같은 폴더 및 파일 구조는 과도할 수 있습니다. 모든 프로젝트에 컬렉션, 메서드 및 게시 코드가 서버에 분리되어 이러한 세분화된 수준의 조직이 필요한 것은 아닙니다. 너무 큰 프로젝트가 없거나 단순히 다른 npm 패키지를 설치하고 배울 필요가 없는 사람들을 위해 다음 기본 폴더 구조를 권장합니다.

핵심 요소는 파비콘 및 기타 정적 자산과 같은 파일이 포함된 공용 폴더와 클라이언트, 공통 및 서버 폴더입니다. 클라이언트 및 서버 폴더에는 (물론) 클라이언트와 서버에서 각각 실행되는 코드가 포함되어야 합니다. 공통 폴더에는 클라이언트와 서버 모두에서 액세스할 수 있어야 하는 코드가 포함되어 있습니다. 이것의 예는 우리가 잠시 논의할 스키마 코드입니다.

가장 낮은 수준의 구성을 수행하는 두 가지 방법이 있습니다. 하나는 파일 유형별이고 두 번째는 기능별입니다. 파일 유형별 구성은 예를 들어 클라이언트/템플릿 폴더에 세 개의 폴더가 있음을 의미합니다. 하나는 JavaScript 파일용, 하나는 CSS용, 하나는 HTML용입니다. HTML 폴더에는 모든 템플릿 HTML 파일(예: Login.html, Main.html 등)이 포함됩니다. JavaScript 및 CSS 폴더에는 각각 해당 유형의 템플릿 파일이 포함됩니다. 반면 기능별 구성은 파일이 구현하는 개념으로 구성하는 것을 의미합니다. 예를 들어 클라이언트/템플릿에는 앱의 로그인 프로세스와 관련된 모든 JavaScript, CSS 및 HTML 파일이 있는 "Login" 폴더가 있습니다. 특정 파일이나 코드 조각을 찾을 수 있는 위치를 더 명확하게 알 수 있도록 하는 기능별 구성을 선호합니다. 그러나 이것은 순전히 흑백이 아니며 대부분의 개인과 팀은 이러한 방법을 혼합하여 파일과 폴더를 구성합니다.

스키마: 데이터베이스에 필요하지 않은 경우에도 앱에 필요

내가 논의하고 싶은 두 번째 종류의 구조는 데이터베이스와 연관되어 있습니다. 이 문서에서는 사용자가 MongoDB를 사용하고 있다고 가정합니다. 그렇지 않은 경우 개념은 여전히 ​​적용되지만 세부 사항은 적용되지 않습니다. MongoDB를 사용하는 사람들은 데이터를 비정형으로 저장하는 방식을 허용한다는 것을 알고 있습니다. MongoDB는 NoSQL 문서 저장소 데이터베이스이므로 데이터 "유형"에 대해 고정된 스키마가 없습니다. 이 자유로움은 모든 객체가 어떤 엄격한 형식으로 표준화되었는지 확인하는 것에 대해 걱정할 필요가 없다는 것을 의미합니다. 실제로 원하는 경우 앱의 모든 데이터를 단일 컬렉션에 넣을 수 있습니다. 그러나 프로덕션 품질의 앱을 만드는 것과 관련하여 이것은 실제로 바람직하지 않습니다. 이것을 관리하고 쓰기 요청의 유효성 검사와 같은 유용한 기능을 추가하기 위해 두 개의 멋진 Meteor 패키지인 Aldeed의 SimpleSchema 및 Collection2를 사용할 수 있습니다.

이름에서 알 수 있듯이 SimpleSchema 패키지를 사용하면 앱의 개체를 반응적으로 확인할 수 있습니다. GitHub에서 문서를 확인하세요. Collection2 패키지는 SimpleSchema에서 부트스트랩되며 Meteor 컬렉션에 적절한 스키마를 가져올 수 있습니다. 이를 통해 스키마가 첨부된 모든 컬렉션에 대한 클라이언트 및 서버 측 쓰기 요청의 자동 유효성 검사가 가능합니다. 이 두 패키지는 매우 심오하고 사용자 정의가 가능하므로 몇 단락으로 완전한 이해를 제공하기 어렵습니다. 그보다는 Aldeed가 세부적으로 컴파일한 자세한 readme를 살펴보는 것이 좋습니다. 이 패키지에서 어떻게 가치를 얻었는지 간단히 이야기하겠습니다. 그들이 활성화한 가장 좋은 점 중 하나는 사용자 양식 입력의 유효성 검사였습니다. 이것은 (계정 패키지에서) Meteor 사용자 문서의 유효성을 검사하는 데 유용합니다. 기본적으로 Meteor Users는 놀랍도록 복잡한 암시적 스키마를 가지고 있습니다. 다음은 Aldeed가 매우 친절하게 제공한 코드의 일부 사진입니다.

 Schema.UserProfile = new SimpleSchema({ firstName: { type: String, optional: true }, lastName: { type: String, optional: true }, birthday: { type: Date, optional: true }, gender: { type: String, allowedValues: ['Male', 'Female'], optional: true }, organization : { type: String, optional: true }, website: { type: String, regEx: SimpleSchema.RegEx.Url, optional: true }, bio: { type: String, optional: true }, country: { type: Schema.UserCountry, optional: true } });

이는 단순히 사용자 프로필 개체에 대한 스키마입니다. 모든 User 개체의 유효성을 검사하려는 시도는 SimpleSchema 와 같은 전용 패키지 없이는 엉망이 될 것입니다. 이러한 모든 필드는 그림에서 선택 사항으로 표시되지만 적절하게 검증된 사용자 스키마를 원했다면 그렇지 않을 수 있으며 "Schema.UserCountry"와 같은 항목은 실제로 검증을 위해 다른 스키마로 리디렉션됩니다. 이 스키마를 User 개체에 연결하고 이를 반응적으로 우리의 양식에 통합함으로써(아마도 Aldeed의 AutoForm과 같은 패키지를 사용하여) 데이터베이스에 포함되는 것과 포함하지 않는 것을 세부적으로 제어할 수 있어 시간과 노력을 절약할 수 있습니다. 구체적인 용어로 지적하고 논의할 수 있는 애플리케이션에서 데이터가 처리되는 방식에 대한 개념적 모델입니다.

역할: 401 및 403의 경우

Meteor 프로젝트를 구조화하고 개선하기 위한 마지막 제안은 Alanning의 Roles 패키지입니다. 이것은 Meteor에 대한 인증 시스템이며 웹 앱의 모든 부분에 대한 사용자 액세스 수준을 확인할 수 있습니다. 권한은 사용자가 클라이언트에 게시된 Meteor 메서드 또는 데이터에 액세스하려고 할 때 나중에 유효성이 확인되거나 무효화되는 문자열 형태로 사용자 프로필에 첨부됩니다. 예를 들어:

 if (Roles.userIsInRole(Meteor.userId(), "admin")) { tabsArr.push({ name: "Users", slug: "users" }); }

시스템의 핵심은 비교적 단순하지만 애플리케이션의 모든 부분에 대해 복잡하고 세분화된 권한을 허용합니다. 모든 역할이 문자열로 저장되기 때문에 "admin", "admin.division1.manage", "admin.division1.manage.group2" 등 원하는 만큼 깊은 시스템을 설정할 수 있습니다.

이 패키지가 허용하는 자유의 문제는 매우 세분화된 역할 시스템을 추적하기 어려울 수 있다는 것입니다. 패키지는 이름에서 알 수 있듯 사용자가 만든 모든 역할을 검색하는 "getAllRoles"와 같은 기능을 제공하지만, 그 모든 의미가 무엇인지, 주어진 역할이 언제 역할을 수행해야 하는지 추적하는 것은 사용자의 몫입니다. 사용된다. 그리고 "역할"과 "권한"의 차이점이 무엇인지 궁금하신 분들을 위해 이 패키지의 목적을 위해 본질적으로 다르지 않습니다.

마무리

불행히도 기사의 폭 때문에(여기에 언급된 각 패키지는 자체 튜토리얼이 필요함) 특정 패키지에 대해 자세히 설명할 수는 없었지만 "표준화된 ” 당신이 확신할 수 있는 Meteor 애플리케이션은 프로덕션과 대규모로 잘 작동할 것입니다. 더 많은 정보를 찾고 있다면 내가 게시한 링크를 확인하고 이 기사에 포함되지 않았지만 Meteor 앱에 있으면 유용한 한 가지를 더 살펴보십시오. 앱용 REST API를 쉽게 노출할 수 있습니다.

면책 조항으로, 저는 이러한 패키지의 작성자가 아니며 패키지의 기능이나 목표를 잘못 표현한 경우 사과드립니다. 읽어주셔서 감사하고 이 글이 도움이 되었기를 바랍니다. 궁금한 점이 있으면 언제든지 저에게 연락하거나 아래에 의견을 남겨주세요.