نقشهٔ راه بک‌اند: مرحله‌ها، پروژه‌ها و مهارت‌های سنجش‌پذیر

«نقشهٔ راه بک‌اند» اغلب به فهرستی از ابزارها (زبان، فریم‌ورک، دیتابیس، Docker) تبدیل می‌شود که یادگیرنده را در انتخاب گیج می‌کند. این مقاله روش دیگری پیشنهاد می‌کند: هر مرحله با یک پروژهٔ کوچک و چند مهارت سنجش‌پذیر تعریف می‌شود. ترتیب مرحله‌ها و پروژه‌ها پیشنهاد نویسنده است؛ مستندات رسمی (RFC 9110، PostgreSQL 18، OpenAPI، RFC 9457، OWASP، systemd، GitHub Actions؛ خوانده‌شده ۱۹ اکتبر ۲۰۲۶) فقط برای ادعاهای فنی مشخص به کار رفته‌اند. هیچ زمان قطعی یا وعدهٔ شغل نمی‌دهیم چون به فرد، پیش‌زمینه و بازار بستگی دارد. برای زمینه API چیست و انتخاب معماری وب‌اپ را ببینید.

اصل: مهارت سنجش‌پذیر

برای هر مرحله، جملهٔ «می‌توانم ...» بنویسید که با یک آزمون ساده بررسی شود. مثلاً «می‌توانم یک endpoint بنویسم که درخواست نامعتبر را با کد وضعیت درست رد کند». هر مرحله با یک خروجی ملموس (کد در مخزن، README، تست) پایان می‌یابد. این روش جلوی احساس «دانستن» بدون توانایی عملی را می‌گیرد.

مرحلهٔ ۱: یک زبان، HTTP و ابزار پایه

یک زبان را انتخاب کنید (انتخاب تکنولوژی را در مقالهٔ مربوط ببینید: انتخاب تکنولوژی) و تا حد نوشتن برنامه‌های کوچک، خواندن خطا و استفاده از Git پیش بروید. در کنارش HTTP را جدی بگیرید. RFC 9110 معنای روش‌ها را تعریف می‌کند؛ برای نمونه می‌گوید روش idempotent روشی است که اثر چند درخواست یکسان با اثر یک درخواست برابر باشد، PUT و DELETE و روش‌های safe چنین‌اند و POST نیست. این تفاوت در طراحی API و تکرار درخواست پس از خطا مهم می‌شود.

پروژه: یک سرویس کوچک «یادداشت‌ها» با ایجاد، خواندن، ویرایش و حذف در حافظه. مهارت سنجش‌پذیر: هر روش HTTP را درست و با کد وضعیت مناسب به‌کار ببرم و آزمون خودکار بنویسم.

مرحلهٔ ۲: پایگاه‌داده و SQL

به‌جای حافظه، یک پایگاه‌دادهٔ رابطه‌ای (مثلاً PostgreSQL) به‌کار بگیرید. موضوع‌های کلیدی: طراحی جدول و کلید، index، تراکنش و سطح ایزوله. مستند PostgreSQL 18 توضیح می‌دهد Read Committed پیش‌فرض است و هر SELECT snapshot لحظهٔ شروع همان query را می‌بیند؛ CREATE INDEX معمولی نوشتن را قفل می‌کند ولی CONCURRENTLY بدون قفل مانع درج و به‌روزرسانی و حذف می‌سازد؛ و EXPLAIN ANALYZE پرس‌وجو را واقعاً اجرا می‌کند و عوارض جانبی رخ می‌دهد. این جزئیات را در عمل با آزمایش یاد بگیرید.

پروژه: همان سرویس با دیتابیس و migration، به‌علاوهٔ یک گزارش کند و بهینه‌سازی‌اش با index. مهارت: یک پرس‌وجوی کند را با EXPLAIN بخوانم و دلیل کندی را بگویم.

مرحلهٔ ۳: طراحی API و قرارداد

قرارداد API را بنویسید، نه فقط کد. OpenAPI را مستند رسمی «گسترده‌ترین استاندارد صنعتی برای توصیف APIهای جدید» می‌نامد و مزایایی مثل اعتبارسنجی توصیف، تولید مستندات و mock server را برمی‌شمارد. برای خطا از قالب استاندارد مثل RFC 9457 (Problem Details) استفاده کنید. برای تکرار امن درخواست ایجاد، الگوی کلید idempotency (مثلاً در مستند Stripe) را مطالعه کنید. هر دو را در مقالهٔ «API چیست» و مقالهٔ مرتبط این سری دنبال کنید: API چیست.

پروژه: API نسخه‌دار با مستند OpenAPI و پاسخ‌های خطای استاندارد. مهارت: قرارداد را بدون خواندن کد پیاده‌سازی به یک هم‌تیمی تحویل بدهم و او بتواند آن را مصرف کند.

مرحلهٔ ۴: احراز هویت و امنیت پایه

منابع پایه: OWASP Cheat Sheets دربارهٔ CSRF، مدیریت خطا و لاگ. مدیریت خطا بخشی از امنیت است و خطای مدیریت‌نشده می‌تواند جزئیات داخلی را فاش کند؛ لاگ نباید رمز، توکن و شناسهٔ نشست را مستقیم ثبت کند. در مستند FastAPI آمده امنیت و احراز هویت موضوع پیچیده‌ای است و OAuth2 رمزگذاری ارتباط را مشخص نمی‌کند و انتظار HTTPS دارد. نتیجه: امنیت را از ابتدا و در طراحی لحاظ کنید.

پروژه: افزودن ثبت‌نام، ورود و مجوزدهی به سرویس. مهارت: فهرست تهدیدهای ساده بنویسم و برای هر کدام کنترل مشخص نشان بدهم.

مرحلهٔ ۵: استقرار، CI و مشاهده‌پذیری

سرویس را روی یک سرور یا سرویس ابری مستقر کنید. مستند systemd توضیح می‌دهد Restart= پیش‌فرض no است و on-failure برای خروج غیرصفر و timeout و watchdog است؛ مستند GitHub Actions توضیح می‌دهد هر runner هم‌زمان یک job اجرا می‌کند و هر اجرا در VM تازه است. با آن‌ها یک pipeline بسازید که تست را اجرا کند و استقرار را خودکار کند. مشاهده‌پذیری را از ابتدا با لاگ و سنجه شروع کنید: Monitoring. پشتیبان‌گیری از دیتابیس را فراموش نکنید؛ مستند PostgreSQL سه رویکرد را نام می‌برد: SQL dump، backup سطح فایل‌سیستم و continuous archiving.

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

مرحلهٔ ۶: عمق‌یابی انتخابی

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

نمونهٔ کار

یک پروژهٔ کامل که مراحل ۱ تا ۵ را شامل شود از چند پروژهٔ نیمه‌کاره ارزشمندتر است: مخزن با README، مستند API، تست، pipeline و راهنمای راه‌اندازی. هرچه بتوانید کار را از صفر روی ماشین دیگری اجرا کنید، بهتر. مثال ساختگی: «سرویس رزرو وقت» با ۴ endpoint، PostgreSQL، OpenAPI، ورود، و استقرار روی یک سرور.

اشتباهات رایج

• یادگیری فریم‌ورک پیش از فهم HTTP و SQL.
• جمع‌آوری آموزش بدون ساخت پروژه.
• تغییر مداوم زبان و فریم‌ورک.
• نادیده‌گرفتن تست و استقرار.
• نگرفتن پشتیبان و عدم آزمون بازیابی.
• انتظار زمان و درآمد مشخص.

چطور بفهمیم آماده‌ایم

آمادگی را با ذهنیت «دوره را تمام کردم» نسنجید؛ با چند آزمون عملی بسنجید. آزمون اول: پروژه را از مخزن روی یک ماشین تمیز بالا بیاورید و فقط با README کار کنید. اگر گیر کردید، مستندات ناقص است. آزمون دوم: یک باگ ساختگی در تراکنش یا ایندکس ایجاد کنید و علت را با لاگ و EXPLAIN پیدا کنید. آزمون سوم: یکی از هم‌تیمی‌ها یا دوستان فنی کد و قرارداد API را بخواند و بگوید کجا مبهم است. آزمون چهارم: سرویس را عمداً از کار بیندازید و ببینید پایش، لاگ و پشتیبان به کار می‌آید یا نه.

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

چک‌لیست

1. هر مرحله یک پروژهٔ کوچک و یک مهارت سنجش‌پذیر دارد.
2. HTTP و SQL پیش از فریم‌ورک مرور شده‌اند.
3. API با قرارداد و خطای استاندارد مستند شده است.
4. امنیت پایه در طراحی لحاظ شده است.
5. CI، استقرار، لاگ و پشتیبان آزموده‌شده وجود دارد.
6. یک پروژهٔ کامل با README در مخزن موجود است.

منابع و مراجع

• RFC 9110: HTTP Semantics — IETF (RFC Editor)، 2026-10-19.
• 13.2. Transaction Isolation (PostgreSQL 18) — PostgreSQL Documentation 18، 2026-10-19.
• CREATE INDEX (PostgreSQL 18) — PostgreSQL Documentation 18، 2026-10-19.
• 14.1. Using EXPLAIN (PostgreSQL 18) — PostgreSQL Documentation 18، 2026-10-19.
• Getting started (OpenAPI Documentation) — OpenAPI Initiative (OpenAPI-Learn)، 2026-10-19.
• RFC 9457: Problem Details for HTTP APIs — IETF (RFC Editor)، 2026-10-19.
• Idempotent requests (Stripe API Reference) — Stripe Docs، 2026-10-19.
• Error Handling Cheat Sheet — OWASP Cheat Sheet Series، 2026-10-19.
• Logging Cheat Sheet — OWASP Cheat Sheet Series، 2026-10-19.
• Security — FastAPI Docs، 2026-10-19.
• systemd.service(5) — systemd documentation (freedesktop.org)، 2026-10-19.
• Understanding GitHub Actions — GitHub Docs، 2026-10-19.
• Chapter 25. Backup and Restore (PostgreSQL 18) — PostgreSQL Documentation 18، 2026-10-19.