وب اپلیکیشن چیست؟ فرانت اند، بک اند و دیتابیس به زبان ساده

هر بار که توی یه سایت دکمهٔ «ثبت سفارش» رو می‌زنین، توی کمتر از یه ثانیه یه سفر کامل اتفاق می‌افته. کلیک شما از مرورگر راه می‌افته، به یه کامپیوتر دیگه می‌رسه، یه جا ذخیره می‌شه، و جوابش برمی‌گرده روی صفحه‌تون. تقریباً هر وب‌اپی که می‌شناسین، همین‌طوری کار می‌کنه. تا آخر همین ویدیو بهتون قول می‌دم: سه تیکهٔ اصلی هر وب‌اپ رو می‌شناسین، frontend، backend و دیتابیس؛ سفر یه کلیک رو قدم به قدم دنبال می‌کنین؛ می‌فهمین وقتی از ایجنت (Agent) یه ویژگی جدید می‌خواین، دقیقاً به کجای اپ دست می‌زنه؛ اشتباهی رو یاد می‌گیرین که درِ اپ رو برای هر کسی باز می‌ذاره؛ و آخر ویدیو، با هم یه اپ کوچیک واقعی می‌سازیم و همین سفر رو با چشم خودمون می‌بینیم.

بریم که شروع کنیم!

توی قسمت قبل ای‌پی‌آی (API) رو یاد گرفتیم، و آخرش قول دادیم که بریم سراغ اینکه یه وب‌اپ چطوری کار می‌کنه. حالا وقتشه. وقتی به کلاد کد (Claude Code)، کدکس (Codex) یا آنتی‌گرویتی (Antigravity: ابزار گوگل) می‌گین «یه اپ برام بساز»، چند دقیقه بعد کلی فایل توی چند تا پوشه تحویل می‌گیرین. اگه ندونین هر کدوم از این تیکه‌ها چیکار می‌کنه، نه می‌تونین درست ازش کار بخواین، نه وقتی خراب شد می‌فهمین کجاش خرابه. توی این ویدیو قدم به قدم می‌ریم جلو: وب‌اپ چیه، سه لایهٔ اصلیش با یه مثال ساده، مرورگر و سرور، frontend و ابزارهاش، backend، دیتابیس، سفر یه کلیک، اینکه اپ کجا اجرا می‌شه، فرق سایت ساده با وب‌اپ، کاری که ایجنت با هر ویژگی جدید می‌کنه و چطوری درست ازش بخواین، اشتباه‌های رایج، و در آخر، یه نمونهٔ واقعی که همین امروز می‌تونین بسازین.

خب، وب‌اپ چیه؟ وب‌اپ یه برنامه‌ست که توی مرورگر اجرا می‌شه. نصبش نمی‌کنین؛ یه آدرس می‌زنین، و برنامه همون‌جا جلوتونه. فرقش با یه سایت معمولی چیه؟ یه سایت معمولی، مثل یه بروشور، به همه یه چیز نشون می‌ده؛ می‌خونینش و تموم. ولی وب‌اپ با شما کار می‌کنه. وارد حسابتون می‌شین، یه چیزی می‌نویسین، ذخیره‌ش می‌کنین، و فردا که برمی‌گردین، هنوز سر جاشه. ایمیلی که توی مرورگر باز می‌کنین، بانک آنلاینتون، یه پنل رزرو نوبت، یه فروشگاه اینترنتی؛ همه‌شون وب‌اپ‌ان. و چیزی که بیشتر ما با وایب کدینگ (Vibe Coding) می‌سازیم هم دقیقاً همینه: یه فرم ثبت‌نام، یه داشبورد، یه ابزار کوچیک برای کسب‌وکارمون.

پس فهمیدن ساختار یه وب‌اپ، یعنی فهمیدن همون چیزی که هر روز داریم با ایجنت‌ها می‌سازیم. یادتونه توی قسمت ای‌پی‌آی، رستوران رو مثال زدیم؟ بیاین همون رستوران رو کامل کنیم، چون یه وب‌اپ دقیقاً همین شکلیه. سالن رستوران، همون frontend ـه: میزها، منو، دکوراسیون؛ هر چیزی که مشتری می‌بینه و باهاش کار می‌کنه. آشپزخونه، backend ـه: جایی که مشتری نمی‌بینه، ولی کار اصلی اونجا انجام می‌شه. دستور پخت، قانون‌ها، و اینکه کدوم سفارش قبول بشه و کدوم نه. انبار و دفتر سفارش‌ها، دیتابیس ـه: جایی که همه‌چی نگه داشته می‌شه، تا فردا هم باشه.

و گارسونی که بین سالن و آشپزخونه رفت‌وآمد می‌کنه؟ همون ای‌پی‌آی ـه که قسمت قبل یاد گرفتیم. frontend از طریق ای‌پی‌آی به backend می‌گه چی می‌خواد، و جواب رو می‌گیره. یه نکتهٔ مهم: مشتری هیچ‌وقت مستقیم نمی‌ره توی انبار. همیشه از آشپزخونه رد می‌شه. توی وب‌اپ هم معمولاً همینه؛ frontend مستقیم به دیتابیس دست نمی‌زنه، و backend وسط وایساده. حالا دو تا کامپیوتر رو در نظر بگیرین. یکی، کامپیوتر یا گوشی خود شما، با مرورگرش. یکی دیگه، یه کامپیوتر که یه جای دیگه روشنه، به اسم سرور.

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

ولی کد backend رو کسی نمی‌بینه. این جمله رو یادتون بمونه؛ خیلی از قانون‌های امنیت وب از همین‌جا میاد. frontend از سه تا زبون ساخته می‌شه، و هر کدوم یه کار داره. HTML، اسکلت صفحه‌ست: اینکه کجا تیتر باشه، کجا متن، کجا یه دکمه، کجا یه فرم. CSS، ظاهرشه: رنگ، فونت، فاصله‌ها، و اینکه صفحه روی گوشی چطوری جا بشه. و JavaScript، رفتارشه: اینکه وقتی روی دکمه کلیک می‌کنین چی بشه؛ یه پنجره باز بشه، یه پیام نشون داده بشه، یا یه درخواست به backend بره. یه مثال: یه دکمهٔ «ثبت سفارش».

خودِ دکمه با HTML ساخته می‌شه. اینکه آبی باشه و گوشه‌هاش گرد، کار CSS هست. و اینکه با کلیک، سفارش فرستاده بشه، کار JavaScript هست. یه چیز جالب: توی همین مرورگری که الان دارین، می‌تونین frontend هر سایتی رو ببینین. روی صفحه کلیک راست کنین و Inspect رو بزنین، یا روی Windows کلید F12 رو؛ ابزار توسعه‌دهندهٔ مرورگر باز می‌شه. نگران نباشین، چیزی خراب نمی‌شه؛ هر تغییری اونجا بدین، فقط روی صفحهٔ خودتونه و با یه رفرش برمی‌گرده. اگه کد پروژه‌هایی که ایجنت براتون می‌سازه رو باز کرده باشین، احتمالاً اسم‌هایی مثل React یا Next.js رو دیدین.

این‌ها چی‌ان؟ این‌ها زبون جدید نیستن. ابزارهایی‌ان که روی همون HTML، CSS و JavaScript ساخته شدن، تا ساختن صفحه‌های بزرگ راحت‌تر بشه. مثلاً با React، صفحه رو از تیکه‌های کوچیک می‌سازین، مثل لگو: یه تیکه برای دکمه، یه تیکه برای منو، یه تیکه برای کارت محصول؛ و هر تیکه رو هر جا خواستین دوباره استفاده می‌کنین. Next.js یه قدم جلوتره؛ روی React ساخته شده، و می‌تونه یه بخشی از کار backend رو هم انجام بده. اسم‌ها زیادن، و مدام عوض می‌شن. لازم نیست همه‌شون رو بشناسین.

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

هنوز از این محصول موجودی داریم؟ سه، رازها: کلیدهای ای‌پی‌آی، رمز دیتابیس، و هر چیزی که نباید دست کسی بیفته. توی قسمت ای‌پی‌آی گفتیم کلید مخفی فقط باید روی سرور بمونه؛ این همون سروره. backend رو می‌شه با زبون‌های مختلف نوشت؛ مثلاً JavaScript با Node.js، یا پایتون (Python: یه زبان برنامه‌نویسی). اینجا هم لازم نیست خودتون انتخاب کنین؛ ایجنت انتخاب می‌کنه. فقط بدونین این بخش، مغز اپتونه، و کاربر هیچ‌وقت کدش رو نمی‌بینه. و حالا انبار: دیتابیس. دیتابیس جاییه که اطلاعات اپ نگه داشته می‌شه: کاربرها، سفارش‌ها، پیام‌ها، تنظیمات.

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

اون موقع، قانون‌های دسترسی خودِ دیتابیس، همون نقش آشپزخونه رو بازی می‌کنن. و اگه اون قانون‌ها درست تنظیم نشده باشن، درِ انبار برای همه بازه.

حالا بیاین همهٔ این‌ها رو کنار هم بذاریم، و سفر یه کلیک رو قدم به قدم دنبال کنیم. فرض کنین توی یه فروشگاه آنلاین، روی «ثبت سفارش» کلیک می‌کنین. یک: JavaScript توی مرورگر، اطلاعات سفارش رو جمع می‌کنه، و یه درخواست به backend می‌فرسته؛ همون request که توی قسمت ای‌پی‌آی دیدیم. دو: backend درخواست رو می‌گیره و چک می‌کنه: کاربر وارد حسابش شده؟ محصول موجوده؟ و قیمت رو خودش حساب می‌کنه. سه: backend سفارش رو توی دیتابیس ذخیره می‌کنه. چهار: دیتابیس می‌گه «ذخیره شد»، و backend یه پاسخ برمی‌گردونه؛ معمولاً یه JSON، با یه کد وضعیت مثل ۲۰۰.

و پنج: JavaScript پاسخ رو می‌گیره، و صفحه رو عوض می‌کنه: «سفارش شما ثبت شد». همهٔ این‌ها، معمولاً توی کمتر از یه ثانیه. و وقتی یه جای کار خراب می‌شه، اولین سؤال اینه: سفر توی کدوم یکی از این پنج قدم قطع شده؟ همین سؤال رو از ایجنت هم بپرسین. زبونی که این درخواست‌ها باهاش رفت‌وآمد می‌کنن، HTTP ـه، که قسمت بعدی کامل بهش می‌رسیم. یه سؤال که خیلی‌ها رو گیج می‌کنه: این اپ، الان دقیقاً کجاست؟ سه تا جواب داره. اول، کامپیوتر خودتون. وقتی ایجنت می‌گه «اپ آماده‌ست» و یه دستور مثل npm run dev اجرا می‌کنه، اپ روی کامپیوتر خود شما روشن می‌شه.

آدرسش localhost ـه، که توی قسمت ترمینال (Terminal: جای تایپ دستور) دیدیم. این نسخه فقط برای خودتونه؛ کس دیگه‌ای از کامپیوتر خودش نمی‌تونه بازش کنه. دوم، یه سرور: یه کامپیوتر که همیشه روشنه و به اینترنت وصله، تا هر کسی از هر جایی بتونه اپ رو باز کنه. و سوم، فضای ابری، که بهش می‌گن کلاد (Claude). در واقع اون هم سروره، فقط مال شرکت‌های بزرگه و شما به اندازهٔ مصرفتون اجاره‌ش می‌کنین. لازم نیست خودتون سرور بخرین یا روشن نگهش دارین. به بردن اپ از کامپیوتر خودتون روی یه سرور یا کلاد می‌گن deploy، و اون هم یه قسمت کامل برای خودش داره.

فعلاً فقط این رو بدونین: اینکه اپ روی localhost کار می‌کنه، یعنی هنوز هیچ‌کس جز شما اون رو ندیده. هر چیزی که با وب ساخته می‌شه، وب‌اپ نیست؛ و دونستن این فرق، کلی وقت و هزینه نجات می‌ده. یه سایت استاتیک، فقط frontend ـه: یه سری فایل HTML، CSS و JavaScript، که به همه یه چیز نشون می‌ده. یه صفحهٔ معرفی، یه رزومه، یه صفحه برای معرفی یه محصول. backend نداره، دیتابیس نداره، و نگه داشتنش ارزون و ساده‌ست. ولی به محض اینکه اپ باید یه چیزی رو یادش بمونه، یا به هر کاربر یه چیز متفاوت نشون بده، مثل حساب کاربری، سفارش، پرداخت یا پیام، یه backend و یه دیتابیس لازم دارین.

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

توی frontend: یه دکمه، شاید یه فرم، و کدی که با کلیک، درخواست رو بفرسته. توی backend: یه endpoint تازه، مثلاً /orders، که درخواست رو بگیره، چک کنه، و سفارش رو ذخیره کنه. و توی دیتابیس: یه جدول برای سفارش‌ها، یا چند تا ستون تازه توی جدولی که از قبل بوده. یعنی یه جملهٔ ساده از شما، می‌تونه سه جای مختلف پروژه رو عوض کنه. و خیلی از باگ‌ها (Bug: خطای برنامه) هم دقیقاً سر درز همین سه تا پیش میان: دکمه درست کار می‌کنه، ولی backend اون اطلاعات رو نمی‌شناسه؛ یا backend می‌خواد ذخیره کنه، ولی دیتابیس اون ستون رو نداره.

وقتی این سه لایه رو بشناسین، کار ایجنت رو هم بهتر می‌فهمین، هم بهتر چکش می‌کنین.

حالا که سه لایه رو می‌شناسین، بیاین ببینیم چطوری یه ویژگی جدید رو درست از ایجنت بخوایم. سه تا عادت ساده. یک: قبل از کد، نقشه بخواین. بگین: «قبل از اینکه چیزی بنویسی، بگو توی frontend، backend و دیتابیس چی رو عوض می‌کنی، و کدوم فایل‌ها رو». از کلاد کد، کدکس و آنتی‌گرویتی، هر سه، می‌تونین بخواین اول برنامه‌شون رو بگن، و بعد شروع کنن. دو: بگین داده کجا بمونه. یه جمله مثل «سفارش‌ها باید توی دیتابیس بمونن، نه فقط توی مرورگر»، جلوی کلی سوءتفاهم رو می‌گیره.

سه: بگین قانون‌ها کجا چک بشن. مثلاً «قیمت رو backend حساب کنه، نه frontend»، یا «هر کاربر فقط سفارش‌های خودش رو ببینه». و بعد از اینکه ایجنت کارش رو کرد، خودتون امتحانش کنین: یه بار صفحه رو رفرش کنین. اگه چیزی که ذخیره کرده بودین هنوز هست، یعنی واقعاً به دیتابیس رسیده. حالا سه تا اشتباه رایج؛ اشتباه‌هایی که توی اپ‌های ساخته‌شده با هوش مصنوعی زیاد دیده می‌شن. یک: منطق توی frontend. مثلاً قیمت نهایی یا تخفیف، توی مرورگر حساب بشه. یادتونه گفتیم هر کسی می‌تونه frontend رو ببینه و روی دستگاه خودش تغییرش بده؟

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

ولی کسی که بخواد، می‌تونه کلاً از frontend رد بشه، و مستقیم به backend درخواست بفرسته. پس backend باید همه‌چی رو دوباره چک کنه: ورودی، اجازه، و قیمت. و یه جمله برای ایجنت، که هر سه رو پوشش می‌ده: «فرض کن هر چیزی که از مرورگر میاد ممکنه دستکاری شده باشه، و همه‌چی رو توی backend چک کن». و حالا، قولی که اول ویدیو دادم: یه اپ کوچیک واقعی، و دیدن سفر یه کلیک با چشم خودمون. به کلاد کد، کدکس یا آنتی‌گرویتی بگین: «یه اپ لیست کارها بساز، با یه frontend ساده، یه backend، و یه دیتابیس روی همین کامپیوتر.

اول بگو هر کدوم توی کدوم فایله». بعد بذارین اجراش کنه، و آدرس localhost رو توی مرورگر باز کنین. یه کار اضافه کنین، و صفحه رو رفرش کنین. هنوز هست؟ یعنی به دیتابیس رسیده. حالا جالبش: روی صفحه کلیک راست کنین، Inspect رو بزنین، و برین توی بخش Network. یه کار دیگه اضافه کنین. یه خط تازه اونجا ظاهر می‌شه: این همون درخواستیه که frontend به backend فرستاد. روش کلیک کنین؛ آدرسش، متدش که احتمالاً POST ـه، کد وضعیتش، و JSON ـی که برگشته رو می‌بینین. سفر یه کلیک، جلوی چشمتون.

و برای قدم آخر، از ایجنت بپرسین: «اگه کسی از frontend رد بشه، و مستقیم به backend یه کار خالی یا خیلی طولانی بفرسته، چی می‌شه؟». بعد بخواین که backend جلوش رو بگیره، و دوباره امتحان کنین. اون موقع، دیگه فقط یه اپ نساختین؛ می‌دونین هر تیکه‌ش کجاست و چیکار می‌کنه. پس بیاین مرور کنیم. وب‌اپ یه برنامه‌ست که توی مرورگر اجرا می‌شه، و سه لایه داره. frontend، سالن رستورانه: HTML اسکلتش، CSS ظاهرش، JavaScript رفتارش؛ و هر کسی می‌تونه ببینتش. backend، آشپزخونه‌ست: منطق، قانون‌ها و رازها، روی سرور.

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

توی قسمت بعدی مفاهیم پایه، می‌ریم سراغ HTTP: زبونی که مرورگر و سرور باهاش حرف می‌زنن. می‌بینمتون.