روزی که قبل از خوردن قهوه سعی کردم یک بکاند بسازم
آیا تا به حال سعی کردهاید که صبح دوشنبه یک بکاند راهاندازی کنید—فقط متوجه شوید که API gateway شما در حالت 403 Forbidden به سر میبرد و پایگاه دادهتان مشکل تعهد دارد؟ یک بار این اتفاق برای من افتاد. من فقط یک endpoint کوچک میخواستم—فقط یک /hello کوچک و دوستانه—و به نوعی در نهایت داشتم در مورد VPCها بحث میکردم، انگار که داشتم یک گروهک در هاگوارتز انتخاب میکردم.
خبر خوب این است: Lovable Cloud تلاش میکند تا بخش «ساخت بکاند» را… خب… دوستداشتنی کند. یا حداقل کمتر خشمگینکننده. اگر ۳۰ دقیقه وقت، اتصال Wi-Fi و تحمل چند استعاره را دارید، قدم به قدم به شما نشان خواهم داد که چگونه با Lovable Cloud یک بکاند بسازید—چه چیزهایی را باید زیر نظر داشته باشید و چگونه از تبدیل شدن آن به یک بشقاب اسپاگتی از endpointها جلوگیری کنید.
توجه: این یک راهنمای عملی و کاربردی است. کمتر شعر و شاعری فروشندگان، بیشتر «اینجا را کلیک کنید، این را تایپ کنید، این کار را نکنید.» و بله، ما میخواهیم یک چیز واقعی را ارائه دهیم: یک API کاربردی با احراز هویت، یک پایگاه داده، secrets محیطی، استقرار، مانیتورینگ و یک مسیر سریع برای مقیاسپذیری. یک میانوعده بردارید. ما در حال ارائه هستیم.
Lovable Cloud چیست و چرا بکاند شما باید به آن اهمیت دهد؟
Lovable Cloud را به عنوان یک چاقوی ارتش سوئیسی مدرن برای بکاند در نظر بگیرید: توابع serverless، مسیریابی API، اتصالات پایگاه داده، secrets محیطی و CI/CD—همه اینها برای این است که شما را از نگهداری یک باغوحش خاکی از فایلهای YAML نجات دهد.
- شما کد مینویسید (Node/TypeScript، پایتون—برای اطلاع از موارد جذاب، اسناد را بررسی کنید).
- شما مسیرها را تعریف میکنید (REST). اگر خیلی اهل تجملات هستید، میتوانید GraphQL را لایهبندی کنید یا به JSON بسنده کنید.
- شما یک پایگاه داده مدیریتشده را متصل میکنید (PostgreSQL در اینجا معمولاً محبوبترین انتخاب است).
- شما استقرار میدهید. مقیاس مییابد. دیگر نگران بیدار شدن در ساعت ۳ صبح برای اضافه کردن سرورهای بیشتر نیستید.
اگر مدل ذهنی شما از «بکاند» این است: endpointها + احراز هویت + داده + استقرار + لاگها، Lovable Cloud تلاش میکند تا یک مسیر سریع با بوقهای کمتر و رسیدهای بیشتر باشد.
برنامه بازی برای ساخت یک بکاند با Lovable Cloud
- یک پروژه و repo در Lovable Cloud ایجاد کنید.
- یک API با یک مسیر عمومی و یک مسیر محافظتشده ایجاد کنید.
- یک پایگاه داده PostgreSQL اضافه کنید و یک migration را اجرا کنید.
- متغیرهای محیطی و یک ORM ساده را متصل کنید.
- احراز هویت را اضافه کنید (JWT، session tokens یا OAuth—به انتخاب شما).
- در یک محیط staging استقرار دهید.
- مانیتورینگ/لاگینگ و یک تست خودکار را اضافه کنید.
- بدون شکستن دل خودِ آیندهتان، به production ارتقا دهید.
بله، به نظر زیاد میرسد. نه، تمام هفته طول نخواهد کشید.
مرحله ۱: پروژه Lovable Cloud خود را راهاندازی کنید (همچنین به عنوان بوی پروژه جدید شناخته میشود)
- یک حساب کاربری ایجاد کنید و یک پروژه جدید را شروع کنید. نامی برای آن انتخاب کنید که بعداً آن را تشخیص دهید—«not_final_backend_v7» یک تله است.
- زمان اجرای خود را انتخاب کنید (Node/TypeScript معمولاً برای APIها مورد پسند است).
- در صورت وجود، یک template را انتخاب کنید: «REST API» یا «Serverless Functions» شما را سریعتر از ترس از صفحه خالی به نتیجه میرساند.
شما یک Git repo (متعلق به شما یا آنها) و یک محیط dev دریافت خواهید کرد. اگر بلافاصله یک branch ایجاد کنید («feature/hello-api»)، امتیاز اضافی میگیرید، بنابراین main branch شما به یک موزه زنده از اشتباهات تبدیل نمیشود.
مرحله ۲: اولین endpoint خود را ایجاد کنید (زیرا Hello World هنوز هم جذاب است)
یک مسیر اساسی ایجاد کنید: /api/hello. آن را ساده و خوشحال نگه دارید.
- فایل مسیر:
routes/hello.ts
- تابع: JSON را مانند
{ message: "Hello, world" } برمیگرداند
- به صورت محلی تست کنید: cURL یا HTTP client مورد علاقه خود را استفاده کنید. اگر کد 200 دریافت نکردید، مراحل خود را دوباره بررسی کنید و لاگها را بررسی کنید.
نکته حرفهای: route handlerهای خود را لاغر نگه دارید—هیچ منطق تجاری در داخل endpoint قرار ندهید. منطق را در services قرار دهید. refactorهای آیندهتان از شما تشکر خواهند کرد.
مرحله ۳: بدون احضار ارواح باستانی DevOps، یک پایگاه داده اضافه کنید
PostgreSQL را انتخاب کنید. قابل اعتماد، رابطهای است و به joinها آلرژی ندارد.
- در Lovable Cloud، یک نمونه Postgres مدیریتشده ایجاد کنید.
- اعتبارسنجیها را به عنوان متغیرهای محیطی ذخیره کنید:
DATABASE_URL، DB_USER، DB_PASS، DB_HOST، DB_NAME.
- یک ORM یا query builder را انتخاب کنید (Prisma، Drizzle، Knex). من به دلیل سرعت و سلامت schema به Prisma گرایش دارم.
یک جدول users کوچک ایجاد کنید تا ثابت کنید که کار میکند:
- Schema:
id (uuid)، email (unique)، created_at (timestamp).
- migration را از محیط dev خود اجرا کنید.
- یک endpoint
GET /api/users بنویسید که یک لیست را برمیگرداند. یک POST /api/users اضافه کنید تا یک مورد جدید را درج کنید. آن را با احراز هویت محافظت کنید (مرحله بعدی)، اما در حال حاضر، با یک درج آزمایشی تأیید کنید.
اگر timeoutها یا connection resetها را مشاهده میکنید، بررسی کنید: پورت صحیح، حالت SSL و اینکه آیا به محیط dev شما اجازه داده میشود با DB صحبت کند (قوانین VPC و IP allowlistها عاشق درام هستند).
مرحله ۴: احراز هویتی را اضافه کنید که باعث گریه کاربران نشود
شما گزینههایی دارید:
- احراز هویت مبتنی بر JWT برای APIهای stateless
- Session tokenها با کوکیهای امن (عالی برای برنامههای وب)
- OAuth با Google، GitHub و غیره (عالی برای جلوگیری از برزخ رمز عبور)
برای یک برد سریع، با JWT شروع کنید:
- tokenها را هنگام ورود به سیستم تولید کنید (
POST /api/auth/login).
- امضای secret را در secrets manager Lovable Cloud ذخیره کنید.
- یک middleware ایجاد کنید که هدر
Authorization: Bearer <token> را میخواند.
- مسیرهایی مانند
POST /api/users و هر چیزی که دادهها را تغییر میدهد را محافظت کنید.
به یاد داشته باشید: طول عمر کوتاه token + refresh token = سردردهای کمتر زمانی که دستگاهها گم میشوند یا توسعهدهندگان فراموش میکنند که یک token را در یک نظر YouTube گذاشتهاند (نپرسید).
مرحله ۵: متغیرهای محیطی: Secrets، نه سوغاتی
secrets را با استفاده از environment manager Lovable Cloud متمرکز کنید:
- کلیدهای API شخص ثالث (ارائهدهنده ایمیل، پرداختها)
آنها را برای هر محیط تنظیم کنید (dev، staging، prod). هیچ چیز را hardcode نکنید. نکنید. حتی «فقط برای الان». اینگونه است که داستانهای ترسناک شروع میشوند.
مرحله ۶: بدون توضیح دادن آن به رواندرمانگر آینده خود، در Staging استقرار دهید
روی Deploy کلیک کنید. لاگها را تماشا کنید. نفس بکشید.
- health checkها را تأیید کنید: آیا root یا
/api/health شما ok را برمیگرداند؟
- یک smoke test را اجرا کنید:
GET /api/hello، GET /api/users.
- یک مسیر محافظتشده را با یک token آزمایشی امتحان کنید—تأیید کنید که بدون آن کد 401 دریافت میکنید و با آن کد 200.
اگر cold startها کند هستند، توابع کوچک را در یک سرویس واحد دستهبندی کنید، جایی که منطقی است. Serverless عالی است، اما 400 تابع کوچک میتواند یک ارکستر بدون رهبر باشد.
مرحله ۷: مانیتورینگ را اضافه کنید تا در ساعت ۲ صبح حدس نزنید
- لاگینگ درخواست را فعال کنید (لاگهای ساختاریافته، لطفاً).
- error capture را تنظیم کنید (stack traceها با request ID).
- داشبوردهای latency را اضافه کنید. p95 را تماشا کنید، نه فقط p50. کاربران شما میانگینها را تجربه نمیکنند.
- برای افزایش 5xx و چرخش اتصال DB هشدار ایجاد کنید.
یک خط لاگ واحد با request ID در هر لایه ارزش ۱۰،۰۰۰ پیام Slack را دارد که با «آیا کسی این را میبیند؟» شروع میشود.
مرحله ۸: یک تست بنویسید. سپس دو. سپس خودکار کنید.
کوچک شروع کنید:
- Unit test: یک تابع سرویس که ایمیلها را تأیید میکند یا مجموعها را محاسبه میکند.
- Integration test:
/api/users را با یک DB آزمایشی فراخوانی کنید.
CI را برای اجرای تستها در pull requestها متصل کنید. هیچ PR با تستهای قرمز ادغام نمیشود. امروز به هزار تست نیاز ندارید—فقط مسیرهای حیاتی. مانند کمربند ایمنی.
مرحله ۹: به Production ارتقا دهید (بله، با دقت)
- main را برای یک ساعت مسدود کنید. ابتدا رفع اشکالات را در staging انجام دهید.
- build را ارتقا دهید. یک smoke test پس از استقرار را اجرا کنید.
- rate limiting را در endpointهای عمومی فعال کنید.
- اگر cache میکنید، TTLهای معقولی را تنظیم کنید. اگر cache نمیکنید، آماده باشید تا DB شما با چشمان خسته به شما نگاه کند.
یک طرح rollback را اضافه کنید: داشتن یکی از آنها باعث بدشانسی نمیشود. شما دارید بالغانه رفتار میکنید.
یک بکاند ساده و واقعی که میتوانید در یک بعد از ظهر ارائه دهید
بیایید یک مجموعه ویژگی کوچک—اما واقعی—را متصل کنیم:
- عمومی
GET /api/hello (سلامت و عقل).
- محافظتشده
POST /api/users (ایجاد کاربر) و GET /api/me (کاربر احراز هویتشده را برمیگرداند).
GET /api/users/:id برای جستجوهای مستقیم.
- حذف نرم:
DELETE /api/users/:id deleted_at را تغییر میدهد.
rate limiting را به /api/auth/login اضافه کنید تا رباتها از بکاند شما به عنوان کاردیو استفاده نکنند.
سپس یک ایمیل خوشآمدگویی از طریق ارائهدهنده ایمیل خود بپاشید. پیام را معاملاتی و دوستانه نگه دارید—بازاریابی را برای مسیرهای بازاریابی واقعی ذخیره کنید.
تلههای رایج هنگام ساخت یک بکاند با Lovable Cloud
- وضعیت مشترک در serverless: به cacheهای درون حافظه بین فراخوانیها تکیه نکنید. از Redis (مدیریتشده) یا DB خود استفاده کنید.
- پیکربندی CORS از دست رفته: مبداهای مجاز را تنظیم کنید. به دامنههای برنامه خود محدود کنید. در production به طور کامل wildcard نروید.
- Cold startهای طولانی: وابستگیها را هوشمندانه بستهبندی کنید، حجم هر تابع را کاهش دهید یا مسیرهای داغ را ادغام کنید.
- queryهای بدون فهرست: اگر
GET /api/users شما crawl میکند، یک فهرست در email و created_at اضافه کنید. خودِ آیندهتان از شما تشکر میکند.
- شکستهای بیصدا: همیشه خطاها را با زمینه ثبت کنید. «یک چیزی خراب شد» شعر DevOps نیست.
چگونه کد را ساختاردهی کنیم تا بعداً گریه نکنید
services/ برای منطق تجاری
repositories/ یا db/ برای دسترسی به دادهها
middlewares/ برای احراز هویت، rate limiting، اعتبارسنجی ورودی
lib/ برای helperها (ایمیل، رمزنگاری، APIهای شخص ثالث)
در صورت امکان، توابع را خالص نگه دارید. اثرات جانبی را در لبهها قرار دهید. این کار آزمایش را آسان میکند و اشکالزدایی را کمتر شبیه یک نمایش جنایی میکند.
تنظیمات عملکردی که واقعاً مهم هستند
- از pagination در هر endpoint لیست استفاده کنید. مبتنی بر cursor اگر مجموعههای داده بزرگی دارید.
- ETagها یا last-modified headerها را اضافه کنید تا از ارسال مجدد دنیا در هر درخواست جلوگیری کنید.
- پاسخهای محاسبهشده را برای queryهای گرانقیمت cache کنید.
- در صورت امکان، writeها را دستهبندی کنید. queryهای N+1 زرق و برق اشکالات بکاند هستند—همه جا پخش میشوند.
مبانی امنیتی که نمیتوانید نادیده بگیرید (حتی اگر بخواهید)
- ورودی را در هر مسیر تأیید کنید. schema JSON یا یک lib اعتبارسنجی از حملات غافلگیرانه جلوگیری میکند.
- رمزهای عبور را با Argon2 یا bcrypt هش کنید. هرگز رمزنگاری خودتان را اجرا نکنید. هرگز. لطفاً.
- کلیدها و secrets را به طور منظم بچرخانید. یادآورهای تقویم ارزانتر از نقضها هستند.
- از نقشهای پایگاه داده با حداقل امتیاز استفاده کنید. API شما به قدرتهای superuser نیاز ندارد—هیچ کس نیاز ندارد.
بررسی واقعیت قیمتگذاری: برای رشد برنامهریزی کنید، نه سوزش قلب
Serverless رایگان به نظر میرسد… تا زمانی که نباشد. نظارت کنید:
- جریمههای cold start زمانی که ترافیک ناگهانی است.
- هزینههای Egress برای APIهای پرحرف.
- توابع طولانی مدتی که باید کارهای پسزمینه باشند.
بودجه و هشدارها را تنظیم کنید. اگر مدیر مالی شما یک ایموجی آتش را برای شما ارسال کند، خیلی دیر شده است.
چه زمانی به اسناد، مثالها و یک بررسی عقلانی نیاز دارید
من با دو حقیقت زندگی میکنم: شما فراموش خواهید کرد که چگونه چیزی را پیکربندی کردهاید و باید آن را دوباره در ساعت ۱۱ شب راهاندازی کنید. یک README در repo خود با این موارد نگه دارید:
- دستورات رایج (migrations، تستها، استقرار)
- لیست endpointها با درخواستهای نمونه
آن را برای خودِ جدیدتان در سه ماه دیگر—یا همتیمی جدید واقعی در هفته آینده—دوستانه کنید.
ارزش توجه: یک میانبر برای تحقیق و بررسی کد
ارزش توجه: اگر میخواهید نظر دومی در مورد انتخابهای معماری داشته باشید یا به سرعت بهترین شیوهها را مقایسه کنید، Sider.AI میتواند مانند آن همتیمی بیمعنی عمل کند که طرح شما را بررسی میکند، موارد حاشیهای عجیب و غریب را گوشزد میکند و قبل از ارائه، یک چک لیست به شما میدهد. این کار Deploy را برای شما کلیک نمیکند—اما به شما کمک میکند از رشته Slack «اوه نه» جلوگیری کنید. مرجع سریع: چک لیست بکاند Lovable Cloud شما
- پروژه ایجاد شد، Git تنظیم شد، استراتژی branch
- Endpoint Hello که JSON را برمیگرداند
- پایگاه داده تهیه شد، migration اجرا شد، ORM متصل شد
- احراز هویت در جای خود، secrets در env manager
- Staging مستقر شد، لاگها تمیز هستند، مسیرهای محافظتشده کار میکنند
- مانیتورینگ، هشدارها، داشبوردهای اساسی
- تستها به CI متصل شدهاند، هیچ PR قرمز وجود ندارد
- راهاندازی Production با rate limiting و طرح rollback
این را به مانیتور خود بچسبانید. یا آن را خالکوبی کنید. (لطفاً آن را خالکوبی نکنید.)
نتیجهگیری: با بیتفاوت کردن آن (به روشی خوب)، آن را دوستداشتنی کنید
یک بکاند دوستداشتنی بکاندی است که در حالی که شما خواب هستید بیصدا کار خود را انجام میدهد. با قطعات بیتفاوت و اثباتشده بسازید: endpointهای HTTP، احراز هویت تمیز، یک پایگاه داده قوی و استقرار معقول. Lovable Cloud با حذف درام داربست کمک میکند تا بتوانید روی بخشهایی که مهم هستند تمرکز کنید—محصول شما، کاربران شما و شاید حتی قهوهای که از آن صرفنظر کردید.
/hello را ارائه دهید. /users را اضافه کنید. پیچها را سفت کنید. سپس در حالی که بکاند شما به آرامی کار میکند، به معنای واقعی کلمه هر کار دیگری انجام دهید. این فقط دوستداشتنی نیست—این زندگی است.
پرسش و پاسخ کوتاه: سناریوهای دنیای واقعی
آیا میتوانم APIهای عمومی و خصوصی را در یک پروژه با هم ترکیب کنم؟
بله. از middleware برای دروازهبندی مسیرهای خصوصی و جدا کردن tokenها/کلیدها برای ترافیک machine-to-machine استفاده کنید. دامنهها را محدود نگه دارید.
اگر به کارهای پسزمینه نیاز داشته باشم چه؟
توابع زمانبندیشده یا مبتنی بر صف را برای کارهای طولانی مدت (ایمیلها، گزارشها، همگامسازیها) راهاندازی کنید. درخواستهای کاربر را برای ارسال خبرنامهها مسدود نکنید.
چگونه از تعویض secrets بین staging و prod مانند نوجوانان جلوگیری کنم؟
محیطهای جداگانه. Secrets جداگانه. Guardrailها در CI به طوری که اعتبارسنجیهای staging هرگز به buildهای production نفوذ نکنند.
آیا میتوانم ساده شروع کنم و بعداً به طور کامل microservices شوم؟
قطعاً. برای سرعت، monolith-ish را شروع کنید. نقاط داغ را زمانی که متریکهای شما میگویند «اکنون»، استخراج کنید، نه زمانی که یک پادکست میگوید «microservices جالب هستند».
مراحل بعدی: طرح ۳۰ دقیقهای شما
- ۵ دقیقه: ایجاد پروژه، انتخاب template
- ۱۰ دقیقه: ساخت
/api/hello، اتصال پایگاه داده، اجرای migration
- ۱۰ دقیقه: افزودن احراز هویت JWT، محافظت از
POST /api/users
- ۵ دقیقه: استقرار در staging، اجرای smoke test
همین. شما به تازگی یک بکاند با Lovable Cloud ساختهاید. کار میکند. مقیاس مییابد. و شما هنوز وقت دارید قهوه خود را دوباره گرم کنید.
سوالات متداول
Q1: آیا Lovable Cloud برای مبتدیان که در حال ساخت بکاند هستند مناسب است؟
بله—templates، توابع serverless و environment manager آن اولین بکاند را بسیار کمتر ترسناک میکند. با یک REST API ساده شروع کنید، یک پایگاه داده اضافه کنید، سپس احراز هویت را لایهبندی کنید. شما الگوهای واقعی را بدون درگیر شدن با یک مرکز داده یاد خواهید گرفت.
Q2: چگونه بکاند Lovable Cloud خود را برای production ایمن کنم؟
از JWT یا OAuth استفاده کنید، CORS را قفل کنید و secrets را در environment manager ذخیره کنید. rate limitها را اضافه کنید، ورودی را در هر مسیر تأیید کنید و p95 latency را نظارت کنید تا قبل از اینکه کاربران متوجه شوند، مشکلات را برطرف کنید.
Q3: کدام پایگاه داده با Lovable Cloud برای REST APIها بهترین کار را دارد؟
PostgreSQL انتخاب قابل اعتماد برای اکثر برنامهها است، به خصوص با یک ORM مانند Prisma یا Drizzle. این دادههای رابطهای، تراکنشها و فهرستبندی را بدون درام مدیریت میکند و با رشد ترافیک مقیاس مییابد.
Q4: چگونه cold startها و عملکرد را در بکاندهای serverless مدیریت کنم؟
وابستگیها را هوشمندانه بستهبندی کنید، مسیرهای حیاتی را گرم کنید و از صدها تابع کوچک زمانی که یک سرویس کار میکند، اجتناب کنید. caching و pagination را اضافه کنید و p95 latency را تماشا کنید تا آنچه را که واقعاً مهم است تنظیم کنید.
Q5: آیا میتوانم staging و production را با secrets و URLهای جداگانه مستقر کنم؟
قطعاً. محیطهای جداگانه ایجاد کنید، DATABASE_URL، JWT_SECRET و دامنههای مجزا را تنظیم کنید و buildها را به جلو ارتقا دهید. این کار آزمایش را ایمن و rollbacks را بدون درد نگه میدارد.
