Front-End & Back-End (CSR) – انجمن DEV

Summarize this content to 400 words in Persian Lang
معرفیزمانی که برنامه نویسی را شروع کردم، با PHP ساده شروع کردم و سپس به تدریج به آن تغییر دادم لاراول، اما من همیشه این تصور غلط را در مورد وب سایت ها داشتم، فکر می کردم بک اند و فرانت اند همیشه باید روی یک سرور باشند که همه چیز را مدیریت می کند (مانند فریمورک های رندر سمت سرور)، اما بعد از مدتی متوجه شدم که چیزی به نام ” وجود دارد. React” که یک کتابخانه قابل استفاده مجدد است که مبتنی بر جاوا اسکریپت است و تنها پس از آن متوجه شدم که بله، front end و back end در واقع می توانند در سرورهای جداگانه یا بهتر بگوییم “node” باشند.و این بسیار منطقی بود زیرا به نظر من نگهداری از یک وب سایت/سیستم که دارای چندین ویژگی در هر دو قسمت جلویی و پشتی است کمی پیچیده است.

-در این وبلاگ بیشتر در مورد رندر سمت مشتری (CSR) بحث خواهیم کرد.

-ما آنقدر روی استقرار تمرکز نخواهیم کرد، بنابراین بحثی در مورد ارائه دهندگان خدمات ابری خاص وجود نخواهد داشت.

چه چیزی را می توانیم به عنوان “فرانت اند” در نظر بگیریم؟در زمینه CSR، چندین چارچوب در زبان های برنامه نویسی مختلف وجود دارد،محبوب ترین ها در تجربه من React، Angular و Vue هستند.اهداف متعددی برای این چارچوب ها وجود دارد، اما عمدتاً آن فریم ورک ها (زمانی که در یک “گره” میزبانی می شوند) مسئول تعامل انسانی با وب سایت هستند (اشاره به رابط کاربری و تجربه کاربری UX/UI) تا آن را تا حد ممکن صاف به نظر برسانند. کاربر.در پشت صحنه هر تعامل کاربر با رابط کاربری به این معنی است که یک عمل خاص باید انجام شود (معمولاً توسط باطن) یا برخی محتوا باید نشان داده شود (معمولاً واکشی از پشتیبان برای دریافت داده های خاص)

چه چیزی را می توانیم به عنوان “پشت پایان” در نظر بگیریم؟چیزی که ما می‌توانیم یک Backend در نظر بگیریم، معمولاً یک پایگاه کد است که درخواست‌هایی را که از یک گره جلویی برای پردازش بیشتر (واکشی، اجرای یک روش خاص و غیره) می‌آیند، پردازش می‌کند.فریمورک‌ها و زبان‌های متعددی وجود دارند که در واقع با برنامه‌های مبتنی بر CSR به خوبی کار می‌کنند، زیرا آن‌ها فقط به عنوان یک API برای استفاده از فرانت‌اند عمل می‌کنند:

برای PHP لاراول وجود دارد (اگرچه PHP به دلیل ماهیت مسدودکننده‌اش محدودیت‌هایی در پردازش دارد، اما اگر مقیاس برنامه کوچک تا متوسط ​​باشد، کار کردن با آن بیشتر خوب است)

ExpressJS مینیمالیستی است، بنابراین باید کتابخانه‌هایی را که می‌خواهید با استفاده از NPM خودتان با آنها کار کنید، اضافه کنید، این برای مبتدیان خوب است، زیرا فرد باید خلاق باشد تا ساختار پوشه‌های خود را سازماندهی کند.

NestJS با برخی از ویژگی‌های خارج از جعبه همراه است و همچنین از معماری Micro-services پشتیبانی می‌کند، با این حال از Typescript به شدت استفاده می‌کند، بنابراین هنگام انتخاب چارچوب مناسب برای استفاده باید در نظر گرفته شود.

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

REST API یکی از آنهاست که برای ارائه سبک درخواست/پاسخ به پروتکل HTTP متکی است و همچنین رایج ترین است.
GraphQL روش دیگری برای “پرس و جو کردن” داده ها از back-end به روشی دقیق تر است، بنابراین از شر داده های اضافی که ممکن است در یک درخواست REST API معمولی واکشی شده و بلافاصله دور ریخته شوند، خلاص شوید. (به عنوان مثال می توان آرایه ای از کاربران را واکشی کرد که هر شیء کاربر دارای: “id”، “نام کامل”، “سن”، “نام کاربری”، “گذرواژه”، “ایمیل” است. و سپس برای مثال فقط از “نام کاربری” استفاده کنید. کلیدهای ” و “password” و مانند GraphQL می توانیم به طور خاص “پرس و جو” کنیم که فقط به نام کاربری و رمز عبور نیاز داریم)

علاوه بر این، ما به راهی برای پیگیری کاربرانمان نیاز داریم، به خصوص اگر آنها “ورود به سیستم” باشند یا نه.

کلیدهای API به کمک می آیند و مانند یک کارت دسترسی به یک ساختمان محافظت شده عمل می کنند، معمولاً در هر اتصال از کاربر در Front End، یک تماس API به Back End می رسد (اولین درخواست معمولاً است. یک درخواست HTTP ورود شامل نام کاربری و رمز عبور) سپس پشتیبان درخواست را پردازش می‌کند و اگر همه چیز خوب پیش رفت، بک‌اند یک کلید API منحصربه‌فرد برای Front End صادر می‌کند تا برای هر درخواست اضافی دیگری ذخیره شود.

در اکثر چارچوب‌هایی که رابط کاربری را مدیریت می‌کنند، همیشه یک مفهوم “ذخیره‌سازی محلی” وجود دارد. در اندروید “Shared Preferences” است، در دسکتاپ می تواند یک فایل رمزگذاری شده برای ذخیره داده های حساس و غیره باشد.

در این زمینه ما هم همینطور است، ما کلید(های) API را در پیاده سازی ذخیره داده محلی موجود (یا هر کلید/مقدار ذخیره محلی داده محلی) که در دسترس ما است، ذخیره می کنیم، در React “ذخیره محلی” آن است.

انواع کلید API

انواع بسیاری از کلیدهای API با نقش‌های خاص، مزایا و ناخوشایند وجود دارد، در این مقاله من روی JsonWebTokens (JWT) و کلیدهای کلاسیک تولید بر اساس تقاضا تمرکز خواهم کرد.

کلیدهای کلاسیک API: معمولاً یک هش تولید شده توسط back-end با در نظر گرفتن شناسه های کاربر خاصی که وارد سیستم می شود، پس از آن در پایگاه داده (بیشتر موارد رابطه ای) و در هر درخواست (غیر از ورود به سیستم) ذخیره می شود. ، کلید در پایگاه داده ما جستجو می شود، اگر پیدا شد، درخواست معتبر است، اگر نه (یا به نحوی منقضی شده است) باید یک کد HTTP خاص را برای اعلام آن برگردانیم.

توکن JWT: همان چیزی است که یک هش توسط back-end ایجاد می شود، اما لزوماً در پایگاه داده ذخیره نمی شود، چرا؟ زیرا بک‌اند می‌تواند تأیید کند که آیا توکن قانونی است یا منقضی نشده است، بدون اینکه حتی با پایگاه داده تعامل داشته باشد، زیرا این بیشتر یک محاسبات الگوریتمی است تا یک دستور SQL. اطلاعات احراز هویت (مانند نام کاربری، رمز عبور) و تاریخ انقضا (ممکن است دقیقه، ساعت، روز و غیره) باشد. با دریافت کلید در بک‌اند برای انجام یک کار خاص، بک‌اند روش «verify_if_token_is_legit» را اجرا می‌کند که همانطور که قبلا ذکر شد، فقط ریاضی رمزنگاری است و پس از آن، بک‌اند حتی می‌تواند به اطلاعات احراز هویتی که بسته‌شده است دسترسی پیدا کند. در آنجا قبل از ایجاد آن کلید.