واقعاً درون اپی که با هوش مصنوعی ساخته شده چه چیزی هست: یک تور برای غیربرنامهنویسها
اگر چیزی را با یک اپساز هوش مصنوعی منتشر کردهاید و میخواهید بفهمید به چه چیزی نگاه میکنید، این هم یک تور راهنمای دوستانه از اجزای آن — بدون اصطلاحات پیچیده.
یک توصیف تایپ کردید، روی برو زدید، و بیست دقیقه بعد یک اپ کارآمد داشتید. عالی. اما حالا روی «مشاهدهٔ فایلها» کلیک کردهاید و به یک درخت پوشه خیره شدهاید که انگار به زبانی دیگر نوشته شده. package.json چیست؟ چرا چهل چیز در node_modules هست؟ «اسکیما» یعنی چه و چرا یکی دارید؟
این مطلب یک تور راهنماست. نه یک آموزش — یک تور. بعد از خواندنش بلد نخواهید بود خودتان هیچکدام از این فایلها را بنویسید، اما دفعهٔ بعد که چیزی عجیب به نظر رسید، خواهید دانست به کدام گوشهٔ اپ اشاره کنید.
در سراسر مطلب از سه مثال جاری استفاده میکنم، تا بخشهای انتزاعی چیزی ملموس برای چنگ زدن داشته باشند:
- مایا، یک مسئول بازاریابی، که یک جدول امتیازات معرفی برای تیمش ساخت.
- جردن، یک مربی یوگا، که یک سایت رزرو کلاس ساخت.
- سم، که یک نانوایی دارد، که یک صفحهٔ «پیشسفارش کروسان فردا» ساخت.
هر سه از یک اپساز هوش مصنوعی استفاده کردند. هر سه اپ برای مشتری کاملاً متفاوت به نظر میرسند. زیر پوسته، شکلشان بهطرز شگفتآوری شبیه به هم است.
فرانتاند: آنچه مشتری شما واقعاً میبیند
فرانتاند هر چیزی است که در مرورگر کسی بارگذاری میشود. دکمهها، چیدمانها، فونتها، انیمیشنها، نحوهای که یک فرم بعد از ارسال خودش را پاک میکند. اگر میتوانید ببینیدش، فرانتاند است.
برای مایا، فرانتاند یک جدول امتیازات با رتبه، نام و تعداد معرفیهاست. برای جردن، یک تقویم کلاسها با دکمهٔ «رزرو» است. برای سم، فهرستی از شیرینیها با دکمههای کوچک بهعلاوه و منهای کنار هر کدام است.
درون پروژه، فرانتاند معمولاً در پوشهای با نامی شبیه app/، pages/ یا src/ زندگی میکند. فایلهایی خواهید دید که به .tsx یا .jsx ختم میشوند. هر کدام تقریباً «یک صفحه» یا «یک تکه از یک صفحه» است. سطر جدول امتیازات یک فایل است. سربرگ یک فایل دیگر. صفحهای که همه را به هم گره میزند فایل سوم.
وقتی از اپساز میخواهید «دکمهها را گردتر کن» یا «جدول امتیازات را به سمت راست ببر»، این بخشی است که تغییر میکند.
بکاند: بخشی که فکر میکند
بکاند بخشی است که هیچکس نمیبیند، اما همه به آن وابستهاند. کدی است که جای دیگری اجرا میشود — روی یک سرور، نه در مرورگر مشتری — وقتی چیزی باید اتفاق بیفتد که نباید به مرورگر مشتری اعتماد کرد تنها از پسش بربیاید.
چرا مرورگر نمیتواند همه کار را بکند؟ چون مرورگر دستگاه مشتری است، و نمیتوانید به آن اعتماد کنید. اگر جدول امتیازات مایا شمار معرفیها را صرفاً در مرورگر بهروز میکرد، هر کسی میتوانست راستکلیک کند و ۹٬۰۰۰ معرفی به خودش اضافه کند. پس بکاند جایی است که قوانین زندگی میکنند: «این شخص میتواند این کار را بکند، اما آن یکی را نه»، «این را واقعاً در پایگاه داده ذخیره کن»، «این ایمیل را بفرست».
بکاند معمولاً در پوشهای با نام api/، server/ یا app/api/ زندگی میکند. فایلهای آنجا معمولاً کوتاهاند. هر کدام یک درخواست خاص را مدیریت میکند: «یک رزرو بساز»، «کروسانهای امروز را فهرست کن»، «یک معرفی اضافه کن».
وقتی چیزی در اپ شما کار میکند اما نتیجه نمیماند — روی ارسال کلیک میکنید، یک تأییدیه میبینید، اما فردا داده رفته — تقریباً همیشه باگ در بکاند است.
پایگاه داده: حافظهٔ اپ شما
حافظهٔ اپتان را مثل ردیفی از کمدهای بایگانی تصور کنید. هر کمد روی جلویش یک برچسب دارد. یکی میگوید «کاربران». یکی میگوید «رزروها». یکی میگوید «croissant_orders». درون هر کمد، هر کشو یک سطر است. هر کشو همان مجموعه شکافها را دارد: یک نام، یک ایمیل، یک created_at، یک status.
آن ساختار — «چه کمدهایی وجود دارند، هر سطر چه شکافهایی دارد» — اسکیما نامیده میشود. این مهمترین فایل در پروژه است، با اینکه احتمالاً ظاهرش از همه کسلکنندهتر هم هست. فایلی با نام schema.ts، schema.prisma، یا چیزی درون پوشهای با نام db/ یا migrations/ پیدا کنید. بازش کنید. فهرستی خواهید دید که بازتاب چیزی است که اپ شما واقعاً دربارهٔ جهان به یاد میسپارد.
اسکیمای جردن یک جدول classes، یک جدول bookings و یک جدول users دارد. اسکیمای سم products، orders و order_items دارد. اسکیمای مایا members و referrals دارد. شکل اسکیما شکل محصول است، و به همین خاطر تغییر دادنش بعداً سختتر از تغییر ظاهر دکمههاست.
یک ترفند مفید: اگر میتوانید با کلمات ساده توصیف کنید اپتان چه چیزی را به یاد میسپارد، معمولاً میتوانید اسکیما را توصیف کنید. «نام و ایمیل هر مشتری را به یاد میسپارم. برای هر مشتری، سفارشهایی را که ثبت کرده به یاد میسپارم. برای هر سفارش، اینکه کدام شیرینیها و از هر کدام چندتا را به یاد میسپارم.» آن جمله، تقریباً کلمه به کلمه، اسکیماست.
احراز هویت: نگهبان جلوی در
«احراز هویت» در زبان انگلیسی دو واژهٔ بههمچسبیده است: authentication (تو کی هستی؟) و authorization (مجاز به چه کاری هستی؟). هر دو معمولاً توسط مجموعهٔ کوچکی از فایلها در پوشهای با نام auth/ مدیریت میشوند، یا توسط سرویسی که شاید نامش را بشناسید: Clerk، Auth0، Supabase Auth، NextAuth.
این دو پرسش با هم فرق دارند. Authentication پاسخ میدهد: «آیا این واقعاً مایاست؟» — معمولاً با یک رمز عبور، یک ورود با گوگل، یا یک لینک جادویی که برایش ایمیل میشود. Authorization پاسخ میدهد: «آیا مایا مجاز است معرفیهای دیگران را حذف کند؟» — و پاسخ صادقانه برای اکثر اپهایی که با هوش مصنوعی ساخته شدهاند در هفتهٔ اولشان این است: «یادمان رفت بررسی کنیم.»
این بخشی است که اغلب بیسروصدا خراب است. صفحهٔ ورود کار میکند، پس امن به نظر میرسد. اما بکاند همیشه بررسی نمیکند که شخص واردشده همان شخصی است که دارد سعی میکند دادهٔ او را بخواند. اگر اپ شما هر مفهومی از «دادهٔ من در برابر دادهٔ تو» دارد، صریحاً از اپساز بخواهید: «مطمئن شو کاربران فقط میتوانند دادهٔ خودشان را ببینند و ویرایش کنند.» شگفتزده خواهید شد که این یک جمله چقدر زیاد یک بررسی غایب را آشکار میکند.
یکپارچهسازیها: چیزهایی که نساختید اما بههرحال دارید استفاده میکنید
اینجا جایی است که اکثر غیربرنامهنویسها آنچه واقعاً دارد اتفاق میافتد را دستکم میگیرند. آن چیزی که ایمیل «کروسانهایتان آماده است» سم را میفرستد کد نیست — یک حساب در SendGrid یا Resend است. آن چیزی که پرداخت کلاس جردن را پردازش میکند کد نیست — Stripe است. آن چیزی که عکسهای روی جدول امتیازات مایا را میزبانی میکند کد نیست — یک سرویس ذخیرهسازی مثل S3 یا Cloudinary است.
هر یکپارچهسازی در دو جا ظاهر میشود. یک تکه کوچک کد در بکاند هست که میگوید «هی Stripe، این کارت را شارژ کن». و یک کلید هست — یک رشتهٔ راز طولانی — که جایی امن ذخیره میشود (معمولاً فایلی با نام .env که هیچکس هرگز نباید commitاش کند) و به Stripe ثابت میکند که درخواست از نانوایی سم آمده و نه از یک غریبه.
اگر زمانی تعجب کردید که چرا اپتان ناگهان ایمیل فرستادن را قطع میکند یا پرداختها را قبول نمیکند، علت تقریباً همیشه یکی از اینهاست: یک کلید منقضیشده، یک سقف استفاده که به آن خوردهاید، یا تغییری در سیاستهای یکپارچهسازی. کد خراب نشد. دستدادن خراب شد.
استقرار: چطور به اینترنت میرسد
قطعهٔ آخر بخشی است که پوشهٔ روی دیسک شما را به چیزی تبدیل میکند که مشتریتان میتواند روی یک URL بازدیدش کند. این معمولاً یعنی سه چیز کوچک که با هم کار میکنند:
- میزبان: سرویسی مثل Vercel، Netlify، Fly یا Render که بکاند شما را اجرا میکند و فرانتاندتان را سرو میکند.
- دامنه: نامی مثل
mayas-leaderboard.comکه به میزبان شما اشاره میکند. - بیلد: دستوری که فایلهای منبع درهموبرهم شما را میگیرد و به نسخهٔ سبکتر و سریعتری که واقعاً اجرا میشود تبدیل میکند.
وقتی چیزی بهصورت محلی کار میکند اما در محیط عملیاتی خراب میشود، دردسر معمولاً اینجاست. کلیدی که روی لپتاپ شما تنظیم شده اما روی میزبان نه. کتابخانهای که در محیط توسعه نصب شده اما در عملیاتی نه. پایگاه دادهای که در مرورگر شما وجود دارد اما در سایت زنده نه.
عادت پنجدقیقهای که خرجش را درمیآورد
لازم نیست هر فایل پروژهتان را بخوانید. لازم نیست بدانید اکثرشان چه میکنند. اما باید، هفتهای یکبار، یک مرور پنجدقیقهای انجام دهید که در آن هر یک از پوشههای بالا را باز کنید و با کلمات ساده از اپساز بپرسید چه چیزی تغییر کرد.
مایا هر جمعه بعدازظهر این کار را میکند. تایپ میکند: «این هفته در اسکیما چه چیزی تغییر کرد، و چرا؟» و: «آیا یکپارچهسازی جدیدی در این اپ هست که من درخواستش را نداده باشم؟» پاسخها تقریباً همیشه آرامشبخشاند. آن چند باری که نیستند، مشکلات را وقتی هنوز کوچکاند میگیرد.
این کل هدف فهمیدن اجزاست. نه اینکه برنامهنویس شوید. فقط اینکه بتوانید پرسشهای بهتری بپرسید.
بعد از این کجا برویم
اگر این تور کمک کرد، دو مطلب پیگیر ارزش وقتتان را دارند. باگ «بهنظر-خوب» دربارهٔ این است که وقتی یکی از این اجزا بیسروصدا خراب است چه کنید، و آمادهٔ دمو در برابر آمادهٔ عملیات دربارهٔ این است که چطور بفهمید اپتان از مرحلهٔ اول به دوم رفته. همان نقشه، کاربردهای متفاوت.