فریمورک Meteor: فریمورکی که قول داد فرانت‌اند و بک‌اند رو یکی کنه

قبل از این‌که Next.js و Nuxt و بقیه‌ی meta-framework های امروزی به‌وجود بیان، یه پروژه به اسم Meteor (سال ۲۰۱۲) یه ایده‌ی جسورانه رو دنبال می‌کرد: چرا باید فرانت‌اند و بک‌اند رو با دو تا زبون و دو تا مدل ذهنی جدا بنویسیم، وقتی جاوااسکریپت می‌تونه هر دو طرف رو پوشش بده؟ Meteor یکی از اولین فریمورک‌های full-stack جاوااسکریپتی بود که این ایده رو جدی گرفت و هنوز هم، با این‌که دیگه اسم پرطرفداری نیست، تو بعضی حوزه‌ها (خصوصاً اپلیکیشن‌های real-time) استفاده می‌شه.

ایده‌ی اصلی: یه codebase، دو تا محیط اجرا

تو Meteor، همون فایل جاوااسکریپت می‌تونه هم رو سرور اجرا بشه، هم رو کلاینت؛ فریمورک با یه سیستم build خودش تشخیص می‌ده کدوم بخش کجا باید اجرا بشه. برای این کار از پوشه‌های خاص استفاده می‌کنه:

imports/
  ui/          # کامپوننت‌های React یا Blaze (فقط کلاینت)
  api/         # منطق مشترک و تعریف Collection ها
server/
  main.js      # فقط رو سرور اجرا می‌شه
client/
  main.js      # فقط رو کلاینت اجرا می‌شه

کدی که تو پوشه‌ی server باشه، هیچ‌وقت به مرورگر فرستاده نمی‌شه (نه حتی خودش، نه secret هایی که توش استفاده شده)، و کدی که تو client باشه فقط رو مرورگر اجرا می‌شه. کدی که بیرون از این پوشه‌ها (مثلاً تو imports) باشه، رو هر دو طرف اجرا می‌شه؛ همین قابلیت اشتراک کد بین سرور و کلاینتِ که یکی از اصلی‌ترین وعده‌های Meteor بود.

DDP و reactivity در سطح شبکه

نکته‌ای که Meteor رو واقعاً متفاوت می‌کنه، پروتکل اختصاصیش به اسم DDP (Distributed Data Protocol) است. به‌جای مدل معمول request-response که تو اکثر اپ‌های وب می‌بینی، Meteor یه اتصال WebSocket دائمی بین کلاینت و سرور برقرار می‌کنه و داده رو به‌صورت reactive سینک می‌کنه:

// تعریف یه Collection (شبیه یه جدول/کالکشن دیتابیس)
import { Mongo } from 'meteor/mongo';
export const Tasks = new Mongo.Collection('tasks');

// سمت کلاینت: subscribe به یه دسته از داده
Meteor.subscribe('tasks.all');

// تو یه کامپوننت React، این query خودش reactive است
const tasks = useTracker(() => Tasks.find({}).fetch());

وقتی یه کاربر دیگه یه task جدید اضافه کنه، Collection سمت کلاینت به‌صورت خودکار آپدیت می‌شه و کامپوننت React (به لطف useTracker) دوباره رندر می‌شه؛ همه‌ی این‌ها بدون این‌که خودت مستقیم WebSocket handler بنویسی یا polling بزنی. این دقیقاً چیزیه که Meteor رو برای اپلیکیشن‌های real-time (چت، داشبورد زنده، ابزارهای همکاری تیمی) جذاب می‌کنه.

MongoDB به‌عنوان دیتابیس پیش‌فرض

Meteor از اول با MongoDB طراحی شده و این وابستگی عمیقه؛ نه یه انتخاب سطحی. سیستم reactivity، سینک شدن Collection ها بین سرور و کلاینت، و حتی امکان اجرای query های MongoDB مستقیم تو کلاینت (با یه minimongo که تو حافظه‌ی مرورگر اجرا می‌شه)، همه بر پایه‌ی مدل داده‌ی MongoDB ساخته شدن. اگه پروژه‌ت نیاز به یه دیتابیس رابطه‌ای مثل PostgreSQL داره، می‌شه با یه‌کم کار اضافه بهش وصلش کرد، ولی دیگه از خیلی از مزیت‌های خودکار Meteor بی‌بهره می‌مونی.

مزیت‌ها

سرعت توسعه‌ی اولیه: برای پروتوتایپ کردن سریع یه اپ real-time، کمتر فریمورکی می‌تونه به سرعت Meteor برسه؛ چون خیلی از کارهایی که معمولاً باید دستی پیاده‌سازی کنی (WebSocket، sync داده، hot code push) از قبل آماده‌ست.

Hot code push: Meteor می‌تونه آپدیت‌های جدید رو به کلاینت‌های متصل، بدون نیاز به رفرش کامل صفحه، پوش کنه.

بسته‌بندی کامل: بیلد، bundling، و حتی deploy (با Galaxy، سرویس هاستینگ خود Meteor، یا Docker) همه از قبل تو اکوسیستم فریمورک هماهنگ شدن.

معایب و محدودیت‌ها

وابستگی سنگین به MongoDB: اگه تیمت یا پروژه‌ت به یه دیتابیس رابطه‌ای نیاز داره، Meteor دیگه اون تجربه‌ی یکپارچه رو نمی‌ده.

اکوسیستم کوچیک‌تر و کم‌رونق‌تر: Meteor دیگه اون momentum اوایل دهه‌ی ۲۰۱۰ رو نداره. تعداد کتابخونه‌ها، تعداد سؤال‌های Stack Overflow، و تعداد پروژه‌های جدیدی که باهاش شروع می‌شن به‌طور محسوسی از React یا Vue خام (چه برسه به Next.js یا Nuxt) کمتره.

سایز باندل کلاینت: به‌خاطر minimongo و DDP client که باید رو مرورگر لود بشن، سایز باندل اولیه‌ی Meteor معمولاً بزرگ‌تر از یه اپ ساده‌ی React یا Vue است.

منحنی یادگیری غیرمستقیم: مفاهیمی مثل Collection، publication/subscription، و method call (روش استاندارد Meteor برای mutation) یه مدل ذهنی جدا از چیزیه که تو REST یا GraphQL معمول یاد می‌گیری؛ یعنی دانشش کمتر قابل‌انتقاله به پروژه‌های دیگه.

کجا هنوز منطقیه

اگه داری یه اپ کاملاً real-time می‌سازی (مثل یه ابزار همکاری زنده، یه چت، یا یه داشبورد که باید فوری آپدیت بشه)، و مشکلی با MongoDB به‌عنوان دیتابیس اصلی نداری، Meteor هنوز می‌تونه سرعت توسعه‌ی بالایی بهت بده؛ خصوصاً برای تیم‌های کوچیک یا MVP هایی که سرعت رسیدن به بازار مهم‌تر از انعطاف بلندمدت معماریه.

برای پروژه‌های عمومی‌تر که نیاز به real-time فوری ندارن، یا تیمت ترجیح می‌ده از یه استک رابطه‌ای و ابزارهای مدرن‌تر مثل Next.js یا Nuxt استفاده کنه، احتمالاً امروز گزینه‌های بهتری نسبت به Meteor پیدا می‌کنی؛ نه به این خاطر که Meteor بد شده، بلکه چون بقیه‌ی اکوسیستم جاوااسکریپت از اون موقع به‌طور قابل‌توجهی رشد کرده و خیلی از ایده‌های خوب Meteor (مثل full-stack بودن) رو به روش‌های مدرن‌تری پیاده کردن.