Meteor Uygulamalarında Proje Yapısını Geliştirmek İçin Geliştirici Kılavuzu

Son birkaç yılda, mevcut JavaScript çerçevelerinin sayısında çarpıcı bir artış oldu. Denenmiş ve gerçek AngularJS'den her ay çıkan çerçeve puanlarına kadar, aralarından seçim yapabileceğiniz etkileyici bir çeşitlilik var. Birkaç yıl önce dikkatimi çeken Meteor adlı bir çerçeve. Çoğu çerçevenin aksine Meteor, JavaScript uygulaması geliştirme için eksiksiz bir platform olmayı amaçlar. Meteor'da yeni olanlar için, web sitelerine göz atmanızı tavsiye ederim. Bu makale Meteor'a bir giriş olmayacak. Bunun yerine, Meteor projelerinde yapıyı tanıtmanın bazı basit yollarını keşfedeceğiz.

Meteor'un en büyük faydalarından biri, onunla karmaşık JavaScript uygulamalarını hızlı bir şekilde prototiplemenin çok kolay olmasıdır. Meteor, MongoDB (birleşik bir çözüm) ile etkileşime giren Düğüm tabanlı bir sunucuyla birleştirilmiş bir ön uç şablonlama ve işleme melezi olduğundan, tam yığın bir web uygulaması oluşturmak için gerekli olan ilk kurulumun çoğu sizin için zaten yapılmıştır. Ancak bunun sağladığı geliştirme kolaylığı bir tuzak olabilir. Bir Meteor uygulaması oluştururken kötü uygulamalara düşmek ve bir dizi yapılandırılmamış kodla sonuçlanmak kolaydır. Bunun nasıl önlenebileceğine dair birkaç önerim var.

İskele: Meteor'da Yönetilebilir Dizin Hiyerarşisi

İlk olarak, uygulamanızı oluştururken önerilen klasör yapısını korumak önemlidir. Meteor varsayılan olarak dosyaları proje klasörü içinde herhangi bir yere yerleştirmenize izin verir - isterseniz tüm kodunuzu tek bir dosyada bile tutabilirsiniz. Bu, bir hackathon projesi için işe yarayabilir, ancak normal üretim düzeyindeki ölçeklenebilir uygulamaların neden olduğu karmaşıklığı, sağlam bir yapı olmadan yönetmek zordur.

Bu sorunu çözmek için Chris Mather'ın npm paket demirine bakmanızı tavsiye ederim. Paketin çeşitli konfigürasyon seçenekleri var, bu yüzden burada tarif etmek zor olacak, ancak genel olarak şuna benzer bir proje yapısı inşa ediyor:

 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

Ancak, bazı projeler için bunun gibi bir klasör ve dosya yapısı aşırıya kaçabilir. Her projenin, sunucuda koleksiyonlar, yöntemler ve yayınlama kodu için ayrımlar içeren bu ayrıntılı bir organizasyon düzeyine sahip olması gerekmez. Çok büyük bir projesi olmayanlar veya başka bir npm paketi kurmak ve öğrenmek istemeyenler için bu temel klasör yapısını tavsiye ederim:

Anahtar öğeler, site simgesi ve diğer statik varlıklar gibi dosyaları ve istemci, ortak ve sunucu klasörlerini içeren bir ortak klasördür. İstemci ve sunucu klasörleri (elbette) sırasıyla istemci ve sunucuda yürütülen kodu içermelidir. Ortak klasör, hem istemci hem de sunucu tarafından erişilebilir olması gereken kodu içerir. Bunun bir örneği, birazdan tartışacağımız Şema kodudur.

En düşük düzeyde organizasyon gerçekleştirmenin iki yolu vardır: biri dosya türüne göre, ikincisi işleve göre. Dosya türüne göre düzenleme, örneğin, istemci/şablonlar klasörünüzde, biri JavaScript dosyaları, biri CSS ve biri HTML için olmak üzere üç klasörünüz olacağı anlamına gelir. HTML klasörü, tüm şablon HTML dosyalarınızı, örneğin Login.html, Main.html vb. içerecektir. JavaScript ve CSS klasörleri, sırasıyla kendi türlerinde şablon dosyaları içerecektir. Fonksiyona göre organizasyon ise, dosyaların içerdiği konsepte göre organizasyon anlamına gelir. Örneğin, istemcide/şablonlarda, uygulamanın oturum açma işlemiyle ilişkili tüm JavaScript, CSS ve HTML dosyalarının bulunduğu bir "Giriş" klasörüm olurdu. Belirli dosyaları veya kod parçalarını nerede bulabileceğiniz konusunda daha net olmanızı sağladığı için işleve göre düzenlemeyi tercih ederim. Ancak, tamamen siyah beyaz değildir ve çoğu kişi ve ekip, dosya ve klasörlerini yapılandırmak için bu yöntemlerin bir karışımını kullanır.

Şema: Veritabanınız Olmasa Bile Uygulamanızın İhtiyacı Var

Tartışmak istediğim ikinci tür yapı, veritabanıyla ilişkilidir. Bu makale, MongoDB kullandığınızı varsayar. Değilseniz, kavramlar muhtemelen yine de geçerli olacaktır, ancak ayrıntılar geçerli olmayacaktır. MongoDB kullananlar, verilerimizi depolama şeklimizin yapılandırılmamış olmasına izin verdiğini biliyor. MongoDB bir NoSQL belge deposu veritabanı olduğundan, herhangi bir veri türü için sabit bir şema yoktur. Bu özgürlük, tüm nesnelerin katı bir biçimde standartlaştırıldığından emin olma konusunda endişelenmenize gerek olmadığı anlamına gelir; aslında, isterseniz uygulamanızın tüm verileri tek bir koleksiyona atılabilir. Ancak, üretim kalitesinde uygulamalar yapmak söz konusu olduğunda, bu pek de arzu edilen bir şey değildir. Bunu yönetmek ve yazma isteklerinin doğrulanması gibi faydalı özellikler eklemek için iki harika Meteor paketine dönebiliriz: Aldeed's SimpleSchema ve Collection2.

SimpleSchema paketi, adından da anlaşılacağı gibi, uygulamanızdaki nesneleri reaktif olarak doğrulamanıza olanak tanır. GitHub'daki dokümanlara göz atın. Collection2 paketi SimpleSchema'dan önyüklenir ve Meteor koleksiyonlarına uygun şemalar getirmenize izin verir. Bunun sağladığı şey, kendisine bir şema eklenmiş herhangi bir koleksiyona istemci ve sunucu tarafı yazma isteklerinin otomatik olarak doğrulanmasıdır. Bu paketlerin her ikisi de çok derin ve özelleştirilebilir, bu nedenle birkaç paragrafta bunların tam olarak anlaşılmasını sağlamak zor. Bunun yerine, Aldeed'in ayrıntılar için derlediği ayrıntılı okumalara bakmanızı tavsiye ederim. Ben sadece bu paketlerden nasıl değer kazandığımdan bahsedeceğim. Etkinleştirdikleri en iyi şeylerden biri, kullanıcının form girişinin doğrulanmasıydı. Bu, Meteor Kullanıcı belgelerini doğrulamak için kullanışlıdır (Hesaplar paketinden). Varsayılan olarak, Meteor Kullanıcıları şaşırtıcı derecede karmaşık bir örtük şemaya sahiptir. Aldeed'in sunmak için çok nazik davrandığı kodun bir bölümünün resmi:

 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 } });

Bu, Kullanıcının profil nesnesinin şemasıdır. SimpleSchema gibi amaca yönelik bir paket olmadan User nesnesinin tamamını doğrulamaya çalışmak bir karmaşa olacaktır. Bu alanların tümü resimde isteğe bağlı olarak görünse de, düzgün bir şekilde doğrulanmış bir Kullanıcı şeması isteseydiniz bunlar muhtemelen olmazdı ve “Schema.UserCountry” gibi şeyler aslında doğrulama için diğer şemalara yönlendirilir. Bu şemayı User nesnesine ekleyerek ve bunu tepkisel olarak formlarımıza entegre ederek, belki de Aldeed'in AutoForm'u gibi bir paketle, veritabanlarımıza neyin girip girmediği üzerinde iyi bir kontrol derecesi kazanabiliriz, bu da zaman ve emekten tasarruf sağlar. Uygulamamızda verilerin nasıl işlendiğine dair somut terimlerle gösterilebilecek ve tartışılabilecek kavramsal bir model.

Roller: 401 ve 403'ler için

Bir Meteor projesini yapılandırmak ve geliştirmek için son önerim Alanning'in Rolleri paketidir. Bu, Meteor için bir yetkilendirme sistemidir ve web uygulamanızın herhangi bir bölümü için kullanıcı erişim düzeylerini kontrol etmenize olanak tanır. İzinler, kullanıcı herhangi bir Meteor yöntemine veya müşteriye yayınlanan verilere erişmeye çalıştığında daha sonra doğrulanan veya geçersiz kılınan diziler biçiminde Kullanıcı profiline eklenir. Örneğin:

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

Sistemin özü nispeten basit olsa da, uygulamanızın herhangi bir bölümü için karmaşık ve ayrıntılı izinlere izin verir. Tüm roller dizeler olarak depolandığından, istediğiniz kadar derin bir sistem kurabilirsiniz - “admin”, “admin.division1.manage”, “admin.division1.manage.group2” vb.

Bu paketin izin verdiği özgürlükle ilgili sorun, son derece ayrıntılı bir rol sistemini takip etmenin zor olabilmesidir. Paket, adından da anlaşılacağı gibi, oluşturduğunuz tüm rolleri alan “getAllRoles” gibi işlevler sağlar, ancak bunların tüm anlamlarının ne olduğunu ve belirli bir rolün ne zaman olması gerektiğini takip etmek size kalmıştır. kullanılacak. Ve "roller" ve "izinler" arasındaki farkın ne olduğunu merak edenler için, bu paketin amaçları açısından temelde farklı değiller.

Toplama

Ne yazık ki, makalenin genişliği nedeniyle (burada bahsedilen paketlerin her biri kendi öğreticisini hak ediyor) belirli bir paket hakkında ayrıntıya girmek mümkün değildi, ancak umarım "standartlaştırılmış bir paket" için nasıl çalışabileceğinize biraz ışık tutmuşumdur. "Güvenebileceğiniz Meteor uygulaması, üretimde ve ölçekte iyi çalışacaktır. Daha fazla bilgi arıyorsanız, gönderdiğim bağlantılara göz atın ve bu makaleye ulaşmayan, ancak bir Meteor uygulamasında bulunması yararlı olan bir şeye daha göz atın: Restivus paketi. uygulamanız için bir REST API'sini kolayca ortaya çıkarmak için.

Bir sorumluluk reddi beyanı olarak, bu paketlerin hiçbirinin yazarı değilim ve herhangi bir paketin özelliklerini veya amaçlarını yanlış beyan ettiysem özür dilerim. Okuduğunuz için teşekkür ederim ve umarım bu makale sizin için faydalı olmuştur. Sorularınız için benimle iletişime geçebilir veya aşağıya yorum bırakabilirsiniz.