بک اند اپلیکیشن چیست

بک اند چیست و چرا نصف اپلیکیشن آنجاست؟

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

یک مثال از هر تعریفی روشن تر است: فهرست سفارش های یک فروشگاه. اگر این فهرست روی گوشی ذخیره شود، با عوض کردن گوشی از بین می رود، روی تبلت همان آدم دیده نمی شود، و کسی که فایل های اپ را باز کند می تواند عددها را عوض کند. همین سه جمله کل دلیل وجود بک اند است.

اپ روی گوشی در عمل سه کار می کند. صفحه را می سازد، ورودی کاربر را می گیرد، و درخواست می فرستد. تصمیم گرفتن کار او نیست. این جمله ساده به نظر می رسد و اولین چیزی است که در پروژه های تازه زیر پا گذاشته می شود: تخفیف را اپ حساب می کند و مبلغ نهایی را می فرستد، و بعد معلوم می شود هر کسی می تواند همان درخواست را با هر عددی که دوست دارد بفرستد.

پس تقسیم کار درست این است: اپ نشان می دهد، بک اند تصمیم می گیرد. اگر اپلیکیشن چگونه کار می کند را خوانده باشید، این همان مرز است که این بار از طرف سرور نگاه شده.

داخل بک اند چه چیزهایی هست؟

بک اند یک برنامه واحد نیست، چند قطعه است که هر کدام یک کار می کنند و معمولا با هم روی یک سرور می نشینند.

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

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

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

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

همه اینها روی چیزی اجرا می شوند که در اینترنت چگونه کار می کند از پایین توضیح داده شده: یک ماشین که خاموش نمی شود و روی یک آدرس منتظر می ماند.

وقتی می گویند سرور قطع است، دقیقا چه اتفاقی افتاده؟

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

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

حالت دوم، سرور جواب داده و جوابش خطا بوده. اینجا عدد وضعیت مهم است و دو خانواده دارد: خطای پانصدی یعنی مشکل از سمت سرور است، و خطای چهارصدی یعنی خود درخواست ایراد داشته. یک اپ که هر دو را «سرور قطع است» نشان بدهد، کاربر را دنبال نخود سیاه می فرستد؛ ۴۰۱ یعنی باید دوباره وارد شوی و ۵۰۰ یعنی بنشین و صبر کن.

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

حالت سوم جایی است که بیشترین وقت تیم ها تلف می شود، چون عدد صبر معمولا جایی نوشته شده که کسی سراغش نمی رود. مستندات خود PHP درباره تنظیم request_terminate_timeout می نویسد که این «مهلت سرویس دادن به یک درخواست است که بعد از آن پروسه کارگر کشته می شود»، و صریحا اضافه می کند این گزینه وقتی به کار می آید که max_execution_time جلوی اجرای اسکریپت را نگرفته باشد. یعنی دو عدد در دو فایل جدا وجود دارند و عدد کوچک تر است که حرف آخر را می زند.

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

بک اند آماده بخریم یا خودمان بنویسیم؟

راه سومی هم هست که بیشتر تیم های کوچک آخر سر همان را انتخاب می کنند: بک اند به عنوان سرویس، یعنی سرویسی که پایگاه داده و ورود و ذخیره فایل را آماده تحویل می دهد و شما هیچ سروری بالا نمی آورید. فایربیس گوگل و سوپابیس دو نمونه شناخته شده اند.

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

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

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

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

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

قبل از انتخاب، این چند چیز را از خودتان بپرسید

تصمیم بک اند تقریبا هیچ وقت تصمیم فنی خالص نیست. چهار سوال زیر را جدی جواب بدهید و جواب خودش را نشان می دهد.

یک: اگر فردا کسی درخواستی بفرستد که اپ شما هرگز نمی فرستد، چه اتفاقی می افتد؟ اگر جوابتان «اپ ما این کار را نمی کند» است، هنوز به بک اند فکر نکرده اید. کسی که با اپ شما کار می کند لازم نیست از اپ شما استفاده کند.

دو: کدام عددها را کاربر نباید تعیین کند؟ قیمت، موجودی، امتیاز، نقش. هر کدام از اینها که از سمت اپ می آید، در عمل ورودی کاربر است.

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

چهار: چه کسی نصف شب سرور را بالا می آورد؟ اگر جواب «کسی نیست» است، سرویس آماده گران تر است و ارزانی محسوب می شود.

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