Tauri 2 و Electron دو مسیر برای ساخت برنامه با رابط وب هستند، اما تفاوت معماری آن‌ها را نمی‌توان به جمله «یکی جایگزین دیگری شد» خلاصه کرد. متن قبلی عددهای ثابت درباره حجم کمتر از پنج مگابایت و هفتاد درصد کاهش RAM داشت، بدون پروژه، سیستم‌عامل یا روش اندازه‌گیری. این ادعاها حذف شده‌اند. انتخاب باید از نیاز برنامه، قابلیت‌های سیستم، محیط کاربران و توان تیم شروع شود. رابط HTML و CSS مشترک به معنی قرارداد برابر درباره اجرای کد، بسته‌بندی و امنیت نیست.
WebView سیستم و Chromium همراه
Tauri برای نمایش رابط از WebView سیستم استفاده می‌کند. راهنمای رسمی WebView Versions تفاوت providerها در پلتفرم‌های مختلف را توضیح می‌دهد. این انتخاب می‌تواند بر حجم بسته اثر بگذارد، چون موتور نمایش به همان شکل همراه برنامه بسته‌بندی نمی‌شود. در مقابل، Electron Chromium و Node.js را در معماری خود دارد. معرفی رسمی Electron این مسیر را توضیح می‌دهد. هزینه و مزیت هر روش باید در محیط هدف خوانده شود.
با WebView سیستم، نسخه و قابلیت‌های نمایش ممکن است با دستگاه تغییر کنند. CSS یا API وبی که روی ماشین توسعه موجود است ممکن است روی محیط دیگری شرایط متفاوتی داشته باشد. این تفاوت برای تیمی که از قابلیت جدید استفاده می‌کند مهم است. با موتور همراه، کنترل بیشتری بر نسخه موتور دارید، اما باید به‌روزرسانی و بسته‌بندی آن را مدیریت کنید. هیچ‌کدام مسئولیت سازگاری را حذف نمی‌کنند؛ فقط محل و روش مدیریت آن را تغییر می‌دهند.
حجم نهایی به فایل‌های frontend، دارایی‌ها، pluginها، نمادهای debug و روش توزیع هم وابسته است. عدد یک نمونه Hello World را به برنامه دارای تصویر، database و چند قابلیت native تعمیم ندهید. اگر حجم دانلود مسئله اصلی است، اجزای بسته خودتان را فهرست کنید. گاهی دارایی‌های محصول از تفاوت framework سهم بیشتری دارند. گزارش مقایسه باید معلوم کند چه چیزی اندازه گرفته شده: installer، فایل اجرایی یا حجم نصب‌شده. این‌ها معیارهای برابر نیستند.
مرز frontend و قابلیت native
در Tauri، کد frontend با بخش core و commandهای تعریف‌شده ارتباط می‌گیرد. مدل امنیت رسمی Tauri این مرز و نقش capabilityها را شرح می‌دهد. قابلیت خواندن فایل یا اجرای کار سیستم باید محدود و روشن باشد. یک command عمومی که هر مسیر و هر فرمانی می‌پذیرد، مرز امنی برای UI نمی‌سازد. داده ورودی frontend را همان‌قدر جدی اعتبارسنجی کنید که ورودی یک API بیرونی را بررسی می‌کنید.
Electron نیز main process و renderer دارد. راهنمای Process Model مسئولیت این بخش‌ها را توضیح می‌دهد. renderer نباید بی‌دلیل دسترسی گسترده به Node.js و سیستم داشته باشد. رابط‌های محدود در preload و IPC کمک می‌کنند فقط عملیات لازم در دسترس UI قرار بگیرند. آشنایی تیم با JavaScript ممکن است ساخت را آسان کند، اما مجوز و اعتبارسنجی همچنان کار معماری است. یک زبان مشترک، مرز اعتماد میان فرایندها را از بین نمی‌برد.
برای طراحی API داخلی، نام عملیات را بر پایه کار محصول انتخاب کنید. «ذخیره پیش‌نویس در پوشه برنامه» قرارداد روشن‌تری از «نوشتن هر فایل در هر مسیر» دارد. ورودی، خروجی و خطا را مستند کنید. اگر UI شامل محتوای بیرونی است، دسترسی آن را از بخش مورد اعتماد جدا نگه دارید. وجود یک پنجره برنامه به معنی مورد اعتمادبودن هر script داخل آن نیست. امنیت برنامه رومیزی به اتصال محتوای وب با قدرت native حساس است.
امنیت با انتخاب framework تمام نمی‌شود
بارگذاری HTML یا script نامطمئن می‌تواند مسیر خطرناکی ایجاد کند، به‌ویژه اگر آن محتوا به قابلیت سیستم برسد. راهنمای امنیت Electron درباره محتوا، sandbox و به‌روزرسانی اجزا توصیه‌های مشخص دارد. در Tauri نیز تنظیم CSP و scope قابلیت‌ها باید با نیاز پروژه هماهنگ باشد. نام Rust یا sandbox نباید به شعار «امنیت تضمین‌شده» تبدیل شود. خطای منطقی در command و مجوز نامناسب می‌تواند در هر معماری مسئله ایجاد کند.
راز سرویس بیرونی را در bundle frontend نگه ندارید. کد برنامه توزیع‌شده می‌تواند بررسی شود و فشرده‌سازی از یک کلید، secret امن نمی‌سازد. اگر سرویس به راز مرکزی نیاز دارد، مسیر backend یا قرارداد مناسب دیگری لازم است. برای داده محلی، محل ذخیره و دسترسی حساب سیستم را در نظر بگیرید. اطلاعات مشتری در log یا فایل تنظیمات نباید بدون نیاز باقی بمانند. امنیت باید رفتار کامل برنامه را پوشش دهد، نه فقط یک گزینه در فایل پیکربندی.
به‌روزرسانی برنامه هم جزئی از امنیت است. کانال دریافت، اعتبار فایل و رفتار rollback را مشخص کنید. کاربری که ماه‌ها نسخه قدیمی را اجرا می‌کند ممکن است اصلاح framework را دریافت نکرده باشد. در معماری موتور همراه، انتشار موتور تازه به چرخه برنامه وابسته است؛ در معماری WebView سیستم، بخشی از به‌روزرسانی از محیط می‌آید. هر دو به سیاست روشن نیاز دارند. گزارش تیم باید نشان دهد مسئول پیگیری هر لایه چه کسی است.
پشتیبانی موبایل را جدا ارزیابی کنید
Tauri 2 مسیرهای موبایل را نیز در اکوسیستم خود ارائه می‌کند، اما «کد مشترک» به معنی تجربه یکسان رومیزی و موبایل نیست. ورودی لمس، صفحه کوچک، چرخه عمر برنامه و مجوزهای سیستم تفاوت دارند. plugin لازم ممکن است در همه پلتفرم‌ها قابلیت برابر نداشته باشد. پیش از انتخاب، فهرست عملیات native را بنویسید و وضعیت هرکدام را برای مقصد بخوانید. وعده عمومی cross-platform نباید جای این بررسی مشخص را بگیرد.
در موبایل، کار پس‌زمینه و دسترسی فایل محدودیت‌های خاص دارند. برنامه رومیزی که همیشه باز است با برنامه‌ای که سیستم آن را متوقف می‌کند یکسان نیست. حالت ذخیره و بازیابی را طراحی کنید و اطلاعات مهم را به حافظه موقت وابسته نگذارید. UI نیز باید برای مقصد ترکیب مناسب داشته باشد؛ کوچک‌کردن پنجره رومیزی به اندازه تلفن تجربه کافی نمی‌سازد. برای محصولی که مقصد اصلی‌اش موبایل است، این نیازها می‌توانند بر انتخاب کل معماری اثر بگذارند.
Rust و اکوسیستم را با توان تیم بسنجید
در Tauri ممکن است برای command یا قابلیت سفارشی به Rust و ابزارهای پلتفرم نیاز داشته باشید. همه اعضا لازم نیست از روز اول تخصص یکسانی داشته باشند، اما مالک بخش native باید مشخص باشد. plugin موجود می‌تواند بخشی از کار را پوشش دهد، به شرطی که قرارداد و نگهداری آن مناسب باشد. اگر نیاز اصلی به قابلیت سفارشی پیچیده است، هزینه یادگیری و عیب‌یابی را حساب کنید. استفاده از یک framework برای فرار از حجم بسته نباید هزینه پنهان توسعه را نادیده بگیرد.
Electron برای تیمی با تجربه Node.js ممکن است مسیر آشناتری داشته باشد، ولی dependency و ابزارهای native آن هم نگهداری می‌خواهند. کتابخانه‌ای که در Node.js سرور کار می‌کند لزوماً در بسته رومیزی بدون تغییر توزیع نمی‌شود. addon بومی، معماری CPU و بسته‌بندی می‌توانند شرایط تازه بسازند. از اکوسیستم بزرگ نتیجه نگیرید که هر نیاز با package آماده و بی‌هزینه حل می‌شود. وابستگی مهم را با مقصد واقعی و چرخه انتشار تیم بررسی کنید.
عملکرد را برای همان برنامه اندازه بگیرید
مصرف حافظه به تعداد پنجره‌ها، داده UI، فایل‌ها و کار پردازشی وابسته است. مقایسه یک صفحه خالی با یک برنامه دارای چند renderer منصفانه نیست. زمان آغاز، زمان آماده‌شدن داده و پاسخ تعامل معیارهای جدا هستند. برای گزارش، وضعیت برنامه و سیستم‌عامل را ثبت کنید. حتی اگر یک گزینه در یک معیار بهتر بود، نتیجه را به همه معیارها تعمیم ندهید. محصولی که عملیات فایل سنگین دارد ممکن است گلوگاهی متفاوت از UI دارای نمودارهای زیاد داشته باشد.
کار CPU در مسیر UI می‌تواند رابط را متوقف کند، مستقل از framework بسته‌بندی. طراحی worker یا پردازش جدا به تقسیم مسئولیت نیاز دارد. مقاله Web Workers و پردازش جدا برای بخش مرورگری ادامه مرتبطی دارد. کار native نیز باید طوری سازمان یابد که وضعیت و خطا به کاربر برسد. عملکرد محصول حاصل معماری کامل است و با عوض‌کردن قاب اجرا خودکار اصلاح نمی‌شود.
مهاجرت را از یک قابلیت محدود شروع کنید
اگر برنامه Electron موجود دارید، ابتدا دلیل مهاجرت را بنویسید: حجم، مصرف منابع، موبایل یا مشکل نگهداری. سپس یک قابلیت نماینده انتخاب کنید که هم UI و هم عملیات native لازم را پوشش دهد. نیاز فایل، شبکه، به‌روزرسانی و pluginها را در آن ببینید. نسخه نمایشی فقط رابط نباید مبنای تصمیم درباره کل محصول باشد. اگر مشکل اصلی از داده و state management آمده است، همان مشکل ممکن است در چارچوب جدید هم منتقل شود.
قراردادهای UI و عملیات سیستم را جدا مستند کنید تا بتوانید بخشی از منطق را منتقل کنید. مسیر نصب کاربران و انتقال داده محلی را هم در برنامه مهاجرت بیاورید. مقاله الگوهای Component در React درباره مرزبندی بخش رابط کمک می‌کند، اگر frontend شما React است. برای تصمیم نهایی، قابلیت ضروری، هزینه نگهداری و محیط کاربران را کنار هم بگذارید. Tauri و Electron گزینه‌های متفاوت‌اند و مناسب‌بودن هرکدام باید با همین نیازهای مشخص توضیح داده شود.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!