بک‌اند چیست و چه تفاوتی با فرانت‌اند دارد؟

بک‌اند (Back-end) بخش پشت‌صحنه یک وب‌سایت یا برنامه است که درخواست کاربر را دریافت می‌کند، قوانین کسب‌وکار را اجرا می‌کند، با پایگاه داده و سرویس‌های دیگر ارتباط می‌گیرد و پاسخ مناسب را به فرانت‌اند برمی‌گرداند. کاربر معمولاً کد بک‌اند را مستقیماً نمی‌بیند، اما ورود به حساب، ثبت سفارش، جست‌وجو، محاسبه قیمت، ذخیره فرم و نمایش اطلاعات شخصی بدون آن ممکن نیست.

فرانت‌اند مسئول چیزی است که کاربر می‌بیند و با آن تعامل می‌کند؛ بک‌اند مسئول صحت، امنیت و ماندگاری عملیاتی است که پشت این رابط رخ می‌دهد. این مقاله بک‌اند را با تمرکز بر وظایف، مسیر درخواست، اجزای معماری و مسیر یادگیری توضیح می‌دهد. برای شناخت عمیق‌تر فناوری‌های مرتبط، راهنماهای سرور چیست، PHP چیست و وب‌سایت داینامیک مکمل این مطلب هستند.

بک‌اند دقیقاً چه کاری انجام می‌دهد؟

فرض کنید کاربر فرم ورود را ارسال می‌کند. فرانت‌اند مقدار ایمیل و رمز را از فرم می‌گیرد و یک درخواست امن می‌فرستد. بک‌اند قالب داده را اعتبارسنجی می‌کند، حساب را پیدا می‌کند، رمز واردشده را با مقدار هش‌شده مقایسه می‌کند، محدودیت تلاش ناموفق را می‌سنجد و در صورت موفقیت یک نشست یا توکن معتبر ایجاد می‌کند. پاسخ نهایی ممکن است فقط شامل وضعیت موفق و اطلاعات ضروری کاربر باشد؛ جزئیات حساس پایگاه داده نباید به مرورگر فرستاده شود.

همین الگو برای عملیات دیگر نیز تکرار می‌شود. هنگام ثبت سفارش، بک‌اند موجودی، قیمت، تخفیف، نشانی، روش ارسال و نتیجه پرداخت را با ترتیب درست بررسی می‌کند. اگر دو کاربر هم‌زمان آخرین کالا را بخواهند، سامانه باید از ثبت فروش بیش از موجودی جلوگیری کند. بنابراین بک‌اند فقط «اتصال به دیتابیس» نیست؛ محل اجرای قواعد و تضمین سازگاری داده است.

تفاوت بک‌اند و فرانت‌اند در یک نگاه

دارایی متمایز این راهنما، جدول زیر است که مسئولیت‌ها را بر اساس خروجی قابل آزمون جدا می‌کند. در پروژه واقعی این دو بخش از طریق قرارداد API و مدل داده با یکدیگر هماهنگ می‌شوند.

این مرزبندی به معنای جدایی کامل نیست. توسعه‌دهنده فرانت‌اند برای مدیریت خطا و وضعیت بارگذاری باید قرارداد API را بفهمد؛ توسعه‌دهنده بک‌اند نیز باید بداند داده چگونه مصرف می‌شود. مقاله فرانت‌اند چیست وظایف سمت رابط را با جزئیات بیشتری توضیح می‌دهد.

مسیر یک درخواست از مرورگر تا پایگاه داده

در ساده‌ترین سناریو، مرورگر یک درخواست HTTPS به دامنه می‌فرستد. DNS نشانی سرور را مشخص می‌کند و وب‌سرور درخواست را می‌پذیرد. مسیریاب برنامه بر اساس نشانی و روش HTTP تصمیم می‌گیرد کدام کنترلر یا تابع اجرا شود. پیش از منطق اصلی، میان‌افزارها می‌توانند احراز هویت، محدودیت نرخ، ثبت رویداد و بررسی سربرگ‌ها را انجام دهند.

لایه سرویس قواعد کسب‌وکار را اجرا می‌کند و لایه دسترسی داده با پایگاه داده یا کش ارتباط می‌گیرد. نتیجه به مدل پاسخ تبدیل می‌شود و با کد وضعیت مناسب برمی‌گردد. خطا نیز باید مدیریت شود: پیام داخلی و اطلاعات فنی برای ثبت سرور مناسب است، اما کاربر باید پاسخ روشن و غیرحساس دریافت کند. این مسیر باید قابل ردیابی باشد تا تیم بتواند کندی یا شکست را میان شبکه، برنامه و دیتابیس تفکیک کند.

اجزای اصلی یک سامانه بک‌اند

• وب‌سرور یا دروازه: اتصال ورودی، TLS، فشرده‌سازی و هدایت درخواست را مدیریت می‌کند.
• برنامه: مسیرها، قواعد کسب‌وکار، مجوزها و تبدیل داده را اجرا می‌کند.
• پایگاه داده: اطلاعات پایدار مانند کاربر، سفارش و محتوا را نگه می‌دارد.
• کش: داده پرتکرار را موقت نگه می‌دارد تا زمان پاسخ و بار دیتابیس کاهش یابد.
• صف پیام: کارهای زمان‌بر مانند ارسال ایمیل یا پردازش تصویر را از پاسخ اصلی جدا می‌کند.
• فضای فایل: رسانه و خروجی‌های بزرگ را با سیاست دسترسی مناسب ذخیره می‌کند.
• پایش و لاگ: خطا، عملکرد و رفتار غیرعادی را برای عیب‌یابی ثبت می‌کند.

هر پروژه به همه این اجزا نیاز ندارد. یک برنامه کوچک می‌تواند با یک سرور و پایگاه داده شروع شود. افزودن کش، صف یا چند سرویس فقط زمانی مفید است که مشکل اندازه‌گیری‌شده‌ای را حل کند؛ پیچیدگی زودهنگام هزینه توسعه و عملیات را بالا می‌برد.

API پل ارتباطی فرانت‌اند و بک‌اند است

API قراردادی است که شکل درخواست، پاسخ، خطا و مجوزها را تعیین می‌کند. در REST معمولاً منابع با URL معرفی و عملیات با روش‌هایی مانند GET، POST، PATCH و DELETE بیان می‌شوند. روش‌های دیگر نیز وجود دارند، اما اصل مهم ثبات قرارداد است. نام فیلد، نوع داده و معنای کدهای خطا باید مستند باشد تا تغییر بک‌اند رابط کاربر را ناخواسته خراب نکند.

اعتبارسنجی سمت فرانت‌اند تجربه کاربری را بهتر می‌کند، ولی کافی نیست؛ کاربر یا مهاجم می‌تواند درخواست را خارج از رابط ارسال کند. بک‌اند باید همه ورودی‌ها را دوباره بررسی کند. پاسخ نیز باید حداقل داده لازم را برگرداند. ارسال فیلدهای محرمانه با این فرض که «در صفحه نمایش داده نمی‌شوند» یک خطای امنیتی است.

پایگاه داده و مدل‌سازی اطلاعات

مدل داده مشخص می‌کند چه موجودیت‌هایی وجود دارند و چگونه به هم مرتبط‌اند. در یک فروشگاه، کاربر، کالا، سفارش، ردیف سفارش و پرداخت نقش‌های متفاوتی دارند. اگر همه اطلاعات در یک جدول یا یک فیلد نامنظم ذخیره شوند، گزارش‌گیری و حفظ سازگاری دشوار می‌شود. طراحی خوب محدودیت‌های واقعی مانند یکتایی ایمیل، وضعیت مجاز سفارش و ارتباط هر ردیف با سفارش را ثبت می‌کند.

پایگاه داده رابطه‌ای برای داده ساخت‌یافته و تراکنش‌های منسجم انتخاب رایجی است. پایگاه‌های سندی، کلید-مقدار یا جست‌وجویی نیز برای نیازهای خاص مفیدند. انتخاب باید بر اساس الگوی خواندن و نوشتن، سازگاری، حجم و مهارت تیم باشد؛ محبوبیت یک ابزار به‌تنهایی دلیل کافی نیست. نسخه پشتیبان نیز فقط زمانی معتبر است که بازیابی آن آزمایش شده باشد.

زبان‌ها و فریم‌ورک‌های بک‌اند

بک‌اند را می‌توان با زبان‌های مختلفی ساخت. PHP در سامانه‌های مدیریت محتوا و بسیاری خدمات وب استفاده می‌شود؛ JavaScript و TypeScript با محیط‌های سمت سرور برای تیم‌های تمام‌پشته جذاب‌اند؛ Python در وب، داده و اتوماسیون کاربرد دارد؛ Java، C#، Go و زبان‌های دیگر نیز بسته به نیاز سازمان انتخاب می‌شوند. فریم‌ورک‌ها مسیریابی، اعتبارسنجی، دسترسی داده و ساختار پروژه را ساده‌تر می‌کنند.

انتخاب زبان باید پس از پاسخ به چند پرسش باشد: تیم چه تجربه‌ای دارد؟ اکوسیستم و نگهداری بسته‌ها چگونه است؟ سرویس چه نیاز عملکردی دارد؟ استخدام و پشتیبانی بلندمدت چقدر آسان است؟ آیا سامانه موجود محدودیت فنی دارد؟ یادگیری مفهوم HTTP، پایگاه داده، امنیت و آزمون از حفظ‌کردن دستورهای یک فریم‌ورک ماندگارتر است.

امنیت در بک‌اند چگونه طراحی می‌شود؟

احراز هویت مشخص می‌کند کاربر چه کسی است؛ مجوزدهی تعیین می‌کند آن کاربر اجازه انجام چه کاری را دارد. عبور از مرحله ورود نباید به معنای دسترسی به همه رکوردها باشد. هر عملیات باید مالکیت یا نقش را بررسی کند. رمز عبور باید با الگوریتم مناسب هش شود و هرگز به شکل متن ساده ذخیره یا ثبت نشود.

ورودی نامعتبر می‌تواند به تزریق، دست‌کاری مسیر، آپلود خطرناک یا مصرف بیش‌ازحد منابع منجر شود. استفاده از کوئری پارامتری، محدودیت اندازه، فهرست نوع فایل مجاز، کنترل نرخ و مدیریت امن اسرار از پایه‌های کار است. پیام خطای عمومی نباید مسیر فایل، کوئری یا کلید سرویس را افشا کند. به‌روزرسانی وابستگی‌ها و ثبت رخدادهای مهم نیز بخشی از امنیت مداوم است، نه فعالیتی یک‌باره.

عملکرد و مقیاس‌پذیری

بهینه‌سازی از اندازه‌گیری آغاز می‌شود. زمان پاسخ را می‌توان به شبکه، اجرای برنامه، کوئری دیتابیس و تماس با سرویس بیرونی تقسیم کرد. اگر کوئری بدون ایندکس عامل کندی است، افزودن سرور برنامه مشکل اصلی را حل نمی‌کند. اگر یک سرویس خارجی دیر پاسخ می‌دهد، زمان‌سنج، بازآزمایی محدود و قطع‌کننده مدار می‌تواند رفتار سامانه را قابل کنترل کند.

کش برای داده‌ای مناسب است که خواندن آن پرتکرار و تغییرش محدود است، اما باید سیاست انقضا و بی‌اعتبارسازی روشن داشته باشد. صف پیام کارهای غیرضروری برای پاسخ فوری را عقب می‌اندازد. مقیاس افقی، نمونه‌های بیشتری از برنامه ایجاد می‌کند؛ در این حالت نشست و فایل نباید بی‌دلیل به یک ماشین خاص وابسته باشند. هدف مقیاس‌پذیری، تحمل بار واقعی با هزینه و پیچیدگی قابل قبول است.

آزمون و استقرار بک‌اند

آزمون واحد قواعد کوچک را بررسی می‌کند؛ آزمون یکپارچه‌سازی ارتباط با دیتابیس یا سرویس را می‌سنجد؛ آزمون سرتاسری یک جریان واقعی مانند ثبت سفارش را اجرا می‌کند. ترکیب این سطوح اعتماد بیشتری از تعداد زیاد آزمون سطحی ایجاد می‌کند. داده آزمایش باید از داده واقعی کاربر جدا باشد و سناریوهای شکست، مجوز و هم‌زمانی نیز پوشش داده شوند.

در استقرار، تغییر پایگاه داده باید با نسخه برنامه هماهنگ باشد. مهاجرت ناسازگار می‌تواند نسخه قبلی را از کار بیندازد و بازگشت را دشوار کند. انتشار مرحله‌ای، بررسی سلامت و امکان بازگشت ریسک را کاهش می‌دهند. متغیرهای محیطی و رازها نباید داخل مخزن کد قرار گیرند. پس از انتشار نیز شاخص خطا و زمان پاسخ باید کنترل شود؛ موفقیت فرایند ساخت به معنای سلامت کاربر نهایی نیست.

مسیر یادگیری بک‌اند برای مبتدیان

مسیر مناسب با مبانی وب آغاز می‌شود: HTTP، URL، DNS، درخواست و پاسخ. سپس یک زبان را تا سطح ساخت برنامه کوچک یاد بگیرید. کار با پایگاه داده رابطه‌ای، SQL، طراحی جدول و تراکنش گام بعدی است. پس از آن API، احراز هویت، اعتبارسنجی، آزمون، Git و استقرار را تمرین کنید. تغییر مداوم زبان پیش از ساخت پروژه کامل، یادگیری را پراکنده می‌کند.

پروژه تمرینی خوب باید فراتر از فهرست کارها باشد. برای نمونه، سامانه رزرو ساده با نقش کاربر و مدیر، ظرفیت محدود، لغو، ثبت رخداد و API مستند طراحی کنید. ابتدا مدل داده و قواعد را بنویسید، سپس مسیرهای API و آزمون‌ها را بسازید. در پایان روی سرور آزمایشی مستقر کنید و خطاهای واقعی را ببینید. این چرخه توان حل مسئله را بهتر از دنبال‌کردن آموزش‌های جداگانه نشان می‌دهد.

چه زمانی به توسعه‌دهنده بک‌اند نیاز داریم؟

اگر سایت فقط محتوای ثابت نمایش می‌دهد، ممکن است بک‌اند اختصاصی لازم نباشد. اما ورود کاربر، نقش‌های متفاوت، پرداخت، رزرو، پنل، جست‌وجوی پیشرفته، همگام‌سازی با CRM یا پردازش داده نیازمند منطق سمت سرور است. گاهی سیستم مدیریت محتوا یا سرویس آماده این نیاز را با هزینه کمتر حل می‌کند. ساخت سفارشی زمانی ارزش دارد که قواعد خاص، یکپارچگی یا مقیاس پروژه با راه‌حل آماده سازگار نباشد.

پیش از انتخاب فناوری، جریان‌های اصلی، داده حساس، سطح دسترسی، حجم تقریبی و وابستگی‌های خارجی را مشخص کنید. معماری باید به اندازه مسئله باشد. یک بک‌اند خوب فقط در روز رونمایی کار نمی‌کند؛ قابل آزمون، قابل مشاهده، قابل بازیابی و قابل توسعه برای تیم بعدی است.

جمع‌بندی

بک‌اند موتور عملیاتی یک محصول دیجیتال است: درخواست را می‌گیرد، هویت و مجوز را می‌سنجد، قواعد را اجرا می‌کند، داده را پایدار نگه می‌دارد و پاسخ قابل اعتماد می‌سازد. فرانت‌اند تجربه قابل مشاهده را شکل می‌دهد و این دو با قرارداد API هماهنگ می‌شوند. برای یادگیری یا طراحی بک‌اند، از مفاهیم پایه، مدل داده و یک پروژه کوچک آغاز کنید و امنیت، آزمون و استقرار را بخشی از کار اصلی بدانید، نه مرحله‌ای که پس از پایان توسعه اضافه می‌شود.