Panduan Pengembang untuk Meningkatkan Struktur Proyek di Aplikasi Meteor

Selama beberapa tahun terakhir, telah terjadi peningkatan dramatis dalam jumlah kerangka kerja JavaScript yang tersedia. Mulai dari AngularJS yang teruji dan benar hingga skor kerangka kerja yang keluar setiap bulan, ada keragaman yang mengesankan untuk dipilih. Salah satu yang menarik perhatian saya beberapa tahun yang lalu adalah kerangka kerja yang disebut Meteor. Tidak seperti kebanyakan kerangka kerja, Meteor bertujuan untuk menjadi platform lengkap untuk pengembangan aplikasi JavaScript. Bagi mereka yang baru mengenal Meteor, saya mendorong Anda untuk memeriksanya di situs web mereka. Artikel ini tidak akan menjadi pengantar Meteor. Sebagai gantinya, kami akan mengeksplorasi beberapa cara sederhana untuk memperkenalkan struktur dalam proyek Meteor.

Salah satu manfaat besar Meteor adalah sangat mudah untuk membuat prototipe aplikasi JavaScript yang kompleks dengan cepat. Karena Meteor adalah hibrida dari templating dan rendering front-end yang digabungkan dengan server berbasis Node yang berinteraksi dengan MongoDB (solusi terpadu), sebagian besar penyiapan awal yang diperlukan untuk pembuatan aplikasi web full-stack sudah dilakukan untuk Anda. Namun, kemudahan pengembangan yang diberikan ini bisa menjadi jebakan. Sangat mudah untuk jatuh ke dalam praktik buruk dan berakhir dengan campur aduk kode tidak terstruktur saat membangun aplikasi Meteor. Saya punya beberapa saran bagaimana ini bisa dihindari.

Scaffolding: Hirarki Direktori yang Dapat Dikelola di Meteor

Pertama, penting untuk mempertahankan struktur folder yang direkomendasikan saat membangun aplikasi Anda. Meteor memungkinkan Anda untuk menempatkan file di mana saja di dalam folder proyek secara default - Anda bahkan dapat memiliki semua kode Anda dalam satu file jika diinginkan. Meskipun ini mungkin berhasil untuk proyek hackathon, kerumitan yang ditimbulkan oleh tingkat produksi biasa, aplikasi yang dapat diskalakan sulit dikelola tanpa struktur yang baik.

Untuk mengatasi masalah ini, saya sarankan untuk memeriksa besi paket npm Chris Mather. Paket ini memiliki berbagai opsi konfigurasi sehingga akan sulit untuk dijelaskan di sini, tetapi secara umum ia membangun struktur proyek yang akan terlihat seperti ini:

 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

Namun, untuk beberapa proyek, struktur folder dan file seperti ini bisa jadi berlebihan. Tidak setiap proyek perlu memiliki tingkat organisasi yang halus ini, dengan pemisahan untuk koleksi, metode, dan kode publikasi di server. Bagi mereka yang tidak memiliki proyek terlalu besar atau tidak ingin menginstal dan mempelajari paket npm lainnya, saya merekomendasikan struktur folder dasar ini:

Elemen kuncinya adalah folder publik yang berisi file seperti favicon Anda dan aset statis lainnya, serta folder klien, umum, dan server. Folder klien dan server harus (tentu saja) berisi kode yang dijalankan masing-masing pada klien dan server. Folder umum berisi kode yang harus dapat diakses oleh klien dan server. Contohnya adalah kode Skema, yang akan kita bahas sedikit.

Ada dua cara untuk melakukan tingkat organisasi terendah: satu berdasarkan jenis file, dan yang kedua berdasarkan fungsi. Organisasi menurut jenis file berarti bahwa di folder klien/templat Anda, misalnya, Anda akan memiliki tiga folder - satu untuk file JavaScript, satu untuk CSS, dan satu untuk HTML. Folder HTML akan berisi semua file HTML template Anda, misalnya Login.html, Main.html, dan seterusnya. Folder JavaScript dan CSS akan berisi file template dari jenisnya masing-masing. Organisasi berdasarkan fungsi, di sisi lain, berarti pengorganisasian dengan konsep yang diwujudkan oleh file. Misalnya, di klien/templat, saya akan memiliki folder "Login", dengan semua file JavaScript, CSS, dan HTML yang terkait dengan proses login aplikasi. Saya lebih suka organisasi berdasarkan fungsi karena memungkinkan Anda untuk lebih jelas tentang di mana Anda dapat menemukan file atau potongan kode tertentu. Namun, itu tidak murni hitam dan putih, dan sebagian besar individu dan tim menemukan beberapa campuran metode ini untuk menyusun file dan folder mereka.

Skema: Aplikasi Anda Membutuhkannya Bahkan Jika Basis Data Anda Tidak

Jenis struktur kedua yang ingin saya diskusikan terkait dengan database. Artikel ini mengasumsikan bahwa Anda menggunakan MongoDB. Jika tidak, konsepnya mungkin masih berlaku tetapi spesifikasinya tidak. Mereka yang menggunakan MongoDB tahu bahwa itu memungkinkan cara kami menyimpan data kami menjadi tidak terstruktur. Karena MongoDB adalah database penyimpanan dokumen NoSQL, tidak ada skema tetap untuk "jenis" data apa pun. Kebebasan ini berarti Anda tidak perlu khawatir untuk memastikan bahwa semua objek distandarisasi ke beberapa bentuk kaku, bahkan, semua data aplikasi Anda dapat dimasukkan ke dalam satu koleksi jika diinginkan. Namun, dalam hal membuat aplikasi berkualitas produksi, ini tidak terlalu diinginkan. Untuk mengelola ini dan menambahkan fitur yang berguna seperti validasi permintaan tulis, kita dapat beralih ke dua paket Meteor yang luar biasa: SimpleSchema dan Collection2 dari Aldeed.

Paket SimpleSchema, seperti namanya, memungkinkan Anda memvalidasi objek secara reaktif di aplikasi Anda. Lihat dokumen di GitHub. Paket Collection2 bootstrap dari SimpleSchema dan memungkinkan Anda untuk membawa skema yang tepat ke koleksi Meteor. Apa yang memungkinkan ini adalah validasi otomatis permintaan tulis sisi server dan klien ke koleksi apa pun dengan skema yang menyertainya. Kedua paket ini sangat dalam dan dapat disesuaikan sehingga sulit untuk memberikan pemahaman yang lengkap tentang mereka dalam beberapa paragraf. Sebaliknya, saya sarankan Anda melihat readmes mendetail yang telah dikompilasi Aldeed untuk spesifikasinya. Saya hanya akan berbicara tentang bagaimana saya mendapatkan nilai dari paket-paket ini. Salah satu hal terbaik yang mereka aktifkan adalah validasi input formulir pengguna. Ini berguna untuk memvalidasi dokumen Pengguna Meteor (dari paket Akun). Secara default, Pengguna Meteor memiliki skema implisit yang sangat kompleks. Berikut adalah gambar bagian dari kode yang Aldeed sangat baik untuk tersedia:

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

Itu hanyalah skema untuk objek profil Pengguna. Mencoba memvalidasi semua objek Pengguna akan menjadi berantakan tanpa paket yang dibuat khusus seperti SimpleSchema . Sementara semua bidang itu tampak opsional dalam gambar, jika Anda menginginkan skema Pengguna yang divalidasi dengan benar, mereka mungkin tidak akan melakukannya, dan hal-hal seperti "Schema.UserCountry" sebenarnya mengarahkan ke skema lain untuk validasi. Dengan melampirkan skema ini ke objek Pengguna dan mengintegrasikannya secara reaktif ke formulir kami, mungkin dengan paket seperti Aldeed's AutoForm, kami dapat memperoleh tingkat kontrol yang baik atas apa yang berhasil dan tidak masuk ke database kami, menghemat waktu dan tenaga dengan model konseptual tentang bagaimana data ditangani dalam aplikasi kita yang dapat ditunjukkan dan didiskusikan secara konkret.

Peran: Untuk 401 dan 403

Saran terakhir yang saya miliki untuk menyusun dan meningkatkan proyek Meteor adalah paket Peran Alanning. Ini adalah sistem otorisasi untuk Meteor, dan memungkinkan Anda memeriksa tingkat akses pengguna untuk bagian mana pun dari aplikasi web Anda. Izin dilampirkan ke profil Pengguna dalam bentuk string yang kemudian divalidasi atau tidak valid ketika pengguna mencoba mengakses metode atau data Meteor yang dipublikasikan ke klien. Sebagai contoh:

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

Meskipun inti dari sistem ini relatif sederhana, ini memungkinkan izin yang kompleks dan terperinci untuk bagian mana pun dari aplikasi Anda. Karena semua peran disimpan sebagai string, Anda dapat mengatur sistem sedalam yang Anda suka - “admin”, “admin.division1.manage”, “admin.division1.manage.group2”, dan seterusnya.

Masalah dengan kebebasan yang dimungkinkan oleh paket ini adalah sulit untuk melacak sistem peran yang sangat terperinci. Paket memang menyediakan fungsi seperti "getAllRoles" yang, seperti namanya, mengambil semua peran yang telah Anda buat, tetapi terserah Anda untuk melacak apa semua artinya, dan kapan peran yang diberikan harus digunakan. Dan bagi yang penasaran apa perbedaan antara “role” dan “permissions”, untuk keperluan paket ini pada dasarnya tidak ada bedanya.

Membungkus

Sayangnya, karena luasnya artikel (masing-masing paket yang disebutkan di sini layak mendapatkan tutorialnya sendiri), tidak mungkin untuk membahas secara rinci tentang paket tertentu, tetapi saya harap saya menjelaskan bagaimana Anda dapat bekerja menuju "standarisasi Aplikasi Meteor yang Anda yakini akan bekerja dengan baik dalam produksi dan dalam skala besar. Jika Anda mencari informasi lebih lanjut, lihat tautan yang saya posting dan lihat satu hal lagi yang tidak sampai ke artikel ini, tetapi berguna untuk dimiliki di aplikasi Meteor: paket Restivus, yang memungkinkan Anda untuk dengan mudah mengekspos REST API untuk aplikasi Anda.

Sebagai penafian, saya bukan pembuat paket ini, dan saya minta maaf jika saya salah mengartikan fitur atau tujuan paket apa pun. Terima kasih telah membaca, dan semoga artikel ini bermanfaat bagi Anda. Jangan ragu untuk menghubungi saya dengan pertanyaan apa pun yang mungkin Anda miliki, atau tinggalkan komentar di bawah.