نرم افزار های مبتنی بر وب

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

این روزها وب سایت ها با هم برابری نمی کند. یک وب سایت، از یک وب سایت بازاریابی برای یک محصول تا یک پلت فرم رسانه های اجتماعی پیچیده را شامل می شود. به عنوان یک فرد تازه کار در توسعه وب، درک چشم انداز آسان نیست: آنچه که به عنوان یک وب سایت سنتی با HTML و CSS شروع می شود، که از یک وب سرور بازگردانده می شود، به یک نرم افزار full-stack دشوارتر با سرویس گیرنده–سرویس دهنده پیچیده تبدیل می شود.

اگر در حال حاضر در حال یادگیری HTML، CSS و جاوا اسکریپت هستید، بدون اینکه در وهله اول در مورد اصول وب سایت ها و برنامه های کاربردی وب بدانید، پس این آموزش برای شما مناسب است.

در این راهنما، من می‌خواهم تکامل توسعه وب از وب‌سایت به برنامه وب را به شما نشان دهم که در آن عباراتی مانند کلاینت/سرور، برنامه مشتری/برنامه سرور، فرانت اند/بک‌اند، وب‌سایت/برنامه وب، REST/GraphQL، وب سرور/ نرم افزار کاربردی را به روشنی بیان می‌کنیم.

سرور برنامه، رندر سمت سرور در مقابل رندر سمت سرویس گیرنده، مسیریابی سمت سرور در مقابل مسیریابی سمت مشتری و برنامه های کاربردی full-stack نیز بیان خواهند گردید.

یک وب سایت سنتی

اگر در حال یادگیری توسعه وب هستید، به احتمال زیاد با ساخت وب سایت سنتی با HTML و CSS شروع خواهید کرد. وب سایتی که سبک (CSS) ندارد و هیچ منطقی (جاوا اسکریپت) ندارد فقط با HTML ارائه می شود.

اگر به یک URL خاص در مرورگر خود (به عنوان مثال فایرفاکس) در لپ تاپ یا تلفن هوشمند خود پیمایش کنید، درخواستی از وب سروری که مسئول این URL است، ارسال می شود. اگر وب سرور بتواند درخواست را با یک وب سایت مطابقت دهد، فایل HTML وب سایت را به مرورگر شما بازگرداند.

برای انتقال یک وب سایت به مرورگر، HTTP به عنوان پروتکل ارتباطی برای درخواست ها و پاسخ ها بین مشتری و وب سرور استفاده می شود. به همین دلیل جلوی هر URL یک \”http\” وجود دارد.

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

یک درخواست HTTP با چهار روش ضروری HTTP ارائه می شود که می خواهم در اینجا به آنها رسیدگی کنم:

• GET
• POST
• PUT
• DELETE

فقط متد HTTP GET برای خواندن یک منبع استفاده می شود، متدهای باقی مانده برای نوشتن منابع استفاده می شوند، که در آن منبع می تواند هر چیزی از HTML تا JSON باشد. هر چهار متدرا می توان به عملیات CRUD انتزاع کرد:

• ایجاد
• خواندن
• به روز رسانی
• حذف

ایجاد -> HTTP POST
خواندن -> HTTP GET
به روز رسانی -> HTTP PUT
حذف -> HTTP DELETE

در مثال ما از یک وب سایت، که از یک وب سرور به یک کلاینت با بازدید از یک URL در یک مرورگر ارائه می شود، مرورگر یک متد HTTP GET را برای خواندن یک فایل HTML از سرور وب اجرا می کند.

نرم افزار های مبتنی بر وب اغلب با متد های HTTP فعالیت می کنند و تنها جنس داده ها و رویکرد ارسال آنها متفاوت است.

کلاینت موجودیتی است که از سرور تغذیه می کند . یا منابع را از سرور می خواند یا منابع را روی سرور می نویسد. برای یک وب سایت سنتی، کلاینت مرورگر شما است. اگر به یک URL خاص با مرورگر خود درخواست ارسال کنید، مرورگر شما با یک سرور ارتباط برقرار می کند تا از منابعی (به عنوان مثال HTML) برای نمایش یک وب سایت برای شما درخواست کند. با نگاهی فراتر از وب‌سایت‌های سنتی، نیازی نیست که کلاینت یک مرورگر باشد (مثلاً cURL ).

سرور موجودی است که به یک کلاینت خدمات ارائه می دهد. در مفهوم سنتی یک وب سایت، سرور به درخواست های کلاینت واکنش نشان می دهد. و یا با منابع (مانند HTML، CSS، جاوا اسکریپت) از درخواست های HTTP GET پاسخ می دهد یا دستکاری های درخواست های HTTP POST، PUT، DELETE را تایید می کند. وب سرورهای محبوب، که نوع خاصی از سرورها هستند، NGINX یا Apache هستند.

می توان گفت هیچ کلاینتی بدون سرور و هیچ سروری بدون کلاینت وجود ندارد. آنها با هم کار می کنند، حتی اگر نیازی به حضور در یک مکان ندارند. به عنوان مثال، در حالی که مرورگر شما در دستگاه شما در مکان محلی شما (مثلاً شیراز/ایران) است، وب سروری که یک وب سایت را ارائه می دهد در یک مکان راه دور (مانند تهرا/ایران) قرار دارد.

یک سرور، که فقط یک رایانه دیگر است، معمولاً در جایی غیر از دستگاه محلی شما قرار دارد. به منظور توسعه سرور، ممکن است سرور را روی دستگاه محلی خود نیز داشته باشید (به localhost مراجعه کنید ).

از آنجایی که یک کلاینت لزوماً نیازی به مرورگر در دستگاه محلی شما ندارد، ممکن است در جایی از راه دور نیز باشد. اما در ادامه بیشتر در مورد این موضوع.

تفاوت بین وب سرور و Application Server چیست؟

یک وب سرور منابعی را ارائه می دهد (مانند HTML، CSS، جاوا اسکریپت) که برای ارتباط از طریق HTTP طراحی شده اند. هنگامی که یک کلاینت منابع را از یک وب سرور درخواست می کند، وب سرور با ارسال مجدد منابع به مشتری، درخواست را برآورده می کند. منابع فقط فایل های این سرور هستند. اگر HTML به یک کلاینت ارسال شود، مشتری (در اینجا مرورگر) فقط HTML را اجرا می کند تا آن را ارائه دهد.

در مقابل، یک سرور برنامه (Application Server) منابعی فراتر از HTML، CSS، JavaScript ارائه می دهد. به عنوان مثال، اگر مشتری درخواست داده در قالبی مناسب برای داده باشد ، به همان زبان یا زبان های دیگر میتواند پاسخ دریاف کند(مثلا JSON می تواند ارسال شود و JSON یا XML و … دریاف گردد).

علاوه بر این، یک Application Server به یک پروتکل نیز محدود نمی شود. در حالی که یک وب سرور عمدتاً با پروتکل HTTP کار می کند، یک سرور برنامه می تواند از پروتکل های دیگر نیز استفاده کند. مهمترین واقعیت این است که یک سرور برنامه می تواند منطق پیچیده ای در سمت سرور خود در یک زبان برنامه نویسی خاص داشته باشد (به عنوان مثال جاوا اسکریپت با Node.js ، PHP، جاوا، روبی، سی شارپ).

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

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

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

وقتی مسیر URL را تغییر می‌دهم چه اتفاقی می‌افتد؟

چه اتفاقی می‌افتد اگر کاربر از طریق URL از یک وب‌سایت بازدید کند و در این دامنه (به عنوان مثال webyar.co) از مسیر (به عنوان مثال /about) به مسیر (/home) حرکت کند؟ برای یک وب سایت سنتی، برای هر URL متمایز یک درخواست جدید از یک مشتری به یک وب سرور ارسال می شود.

برای هر URL، یک روش HTTP GET مجزا به وب سرور اختصاصی ارسال می شود تا درخواست را برآورده کند. وقتی کاربر به وب‌سایتی در /about مسیر خود (که صفحه یا مسیر نیز نامیده می‌شود) در یک مرورگر دسترسی پیدا https://webyar.co/about می‌کند، وب سرور تمام اطلاعات مربوط به این URL را به مرورگر ارسال می‌کند. این عمل مسیریابی سمت سرور نامیده می شود ، زیرا سرور تصمیم می گیرد که کدام منبع در هر URL برای مشتری ارسال شود. بعداً با مسیریابی سمت مشتری آشنا خواهید شد.

وقتی وب سایت من بیشتر از HTML باشد چه اتفاقی می افتد؟

یک وب سایت مدرن از HTML (ساختار)، CSS (سبک) و جاوا اسکریپت (منطق) تشکیل شده است. بدون CSS یک وب سایت براق نخواهد بود و بدون جاوا اسکریپت یک وب سایت تعامل پویا نخواهد داشت. پس از همه، CSS و جاوا اسکریپت در فایل هایی مانند HTML نوشته می شود. معمولاً این فایل ها در یک فایل HTML پیوند داده می شوند:

< link href = \" /media/examples/link-element-example.css \" rel = \" stylesheet \" >  
<p>Red text as defined in the external CSS file.</p>

اگر مرورگر از یک وب سرور HTML یک URL را بخواهد، وب سرور فایل HTML را که ممکن است شامل link برچسب های HTML باشد به منابع دیگری مانند فایل های CSS یا جاوا اسکریپت برمی گرداند. برای هر پیوند، درخواست دیگری از وب سرور برای بازیابی فایل ها ارسال می شود.

به این موارد درخواست های آبشار نیز گفته می شود ، زیرا یک درخواست باید منتظر بمانند تا درخواست دیگری تمام شود. در مثال ما، مرورگر نمی داند که باید فایل CSS را قبل از رسیدن فایل HTML با link تگ های HTML درخواست کند. و در مثال بعدی فایل HTML به یک فایل جاوا اسکریپت و CSS پیوند دارد، در حالی که فایل CSS به یک فایل JPG دیگر پیوند می خورد.

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

در نهایت مرورگر تمام منابع (به عنوان مثال HTML، CSS، جاوا اسکریپت، PNG، JPG، SVG) را برای یک URL خاص خواهد داشت و نتیجه دلخواه را برای شما ارائه می کند. پس از آن صفحه اول وب سایت آماده است تا شما به عنوان یک کاربر با آن تعامل داشته باشید.

وب سایت ها در وب 2.0

در نهایت فقط ارائه محتوای ثابت از یک وب سرور کافی نبود. در وب 2.0 ، این امکان برای کاربران فراهم شد که نه تنها مطالب را بخوانند، بلکه بتوانند محتوا ایجاد کنند. که منجر به محتوای پویا شد. روش های HTTP قبلی را به خاطر دارید؟ تا کنون، ما فقط متدهای HTTP GET را برای خواندن منابع در عمل دیده‌ایم، اما در مورد سایر روش‌های HTTP چطور؟

با ظهور سیستم های مدیریت محتوا مانند وردپرس، یک وب سرور باید به کاربران امکان می داد نه تنها منابع را ببینند، بلکه آنها را نیز دستکاری کنند. به عنوان مثال، کاربری که از سیستم مدیریت محتوا استفاده می کند باید بتواند وارد سیستم شود، یک پست وبلاگ ایجاد کند، یک پست وبلاگ را به روز کند، یک پست وبلاگ را حذف کند و از سیستم خارج شود. در این زمان، زبان برنامه نویسی PHP (که می تواند توسط یک وب سرور در سمت سرور تفسیر شود) بهترین نمونه برای این نوع وب سایت های پویا بود.

با داشتن منطق در سمت سرور، توسعه دهندگان قادر به پردازش درخواست های خواندن و نوشتن از کاربران خود هستند. از این رو، اگر کاربر بخواهد یک پست وبلاگ ایجاد کند (عملیات نوشتن)، کاربر باید پست وبلاگ را در یک مرورگر بنویسد و روی دکمه \”ذخیره\” کلیک کند تا محتوا به منطق سمت سرور در حال اجرا برای سرور وب ارسال شود. این منطق تأیید می کند که کاربر مجاز است، محتوای وبلاگ را تأیید می کند و محتوا را در پایگاه داده می نویسد.

از آنجایی که ما هنوز مسیریابی سمت سرور داریم ، وب سرور می تواند کاربر را پس از ایجاد موفقیت آمیز پست وبلاگ به صفحه جدیدی هدایت کند. به عنوان مثال، تغییر مسیر می تواند به پست وبلاگ تازه منتشر شده باشد. اگر هیچ تغییر مسیری وجود نداشته باشد، یک درخواست HTTP POST/PUT/DELETE معمولاً منجر به بازخوانی/بارگذاری مجدد صفحه می‌شود.

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

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

حال، پس از ایجاد یک پست وبلاگ، چگونه یک سرور یک فایل HTML را برای یک پست وبلاگ ارسال می کند، در صورتی که داده های آن ثابت نیست، بلکه در یک پایگاه داده ذخیره می شود؟ اینجاست که اصل رندر سمت سرور (به اشتباه با مسیریابی سمت سرور) وارد عمل می شود.

هر دو، وب 1.0 (با وب سایت های مصرف کننده (محتوای ثابت)) و وب 2.0 (با وب سایت های تولید کننده (محتوای پویا)) HTML را از سرور برمی گرداند. کاربر به یک URL در مرورگر پیمایش می کند و HTML آن را درخواست می کند. با این حال، برای محتوای پویا در وب 2.0، HTML که به مشتری ارسال می شود، دیگر یک فایل HTML ثابت با محتوای ثابت نیست، زیرا اکنون با محتوای پویا از پایگاه داده درون یابی می شود.

<?php if ($expression == true): ?>
  این نشان می دهد که آیا عبارت درست است یا خیر.
<?php else: ?>
  در غیر این صورت این نشان خواهد داد.
<?php endif; ?>

موتورهای قالب‌بندی برای زبان‌های برنامه‌نویسی مختلف (مثلاً Pug برای جاوا اسکریپت در Node.js ، Twig برایJSP PHP برای جاوا، جنگو برای Python) درون یابی HTML و داده‌های پویا را قبل از ارسال به کلاینت فعال می‌کنند. با کمک رندر سمت سرور، محتوای تولید شده توسط کاربر را می توان از سرور به مشتری در HTML با ایجاد HTML در جریان زمانی که مشتری درخواست کرد، ارائه نمود.

آیا ما هنوز در اینجا با یک وب سایت سروکار داریم؟ از نظر فنی بله، اما وب‌سایت‌هایی که با ارائه محتوای پویا از یک وب سرور (یا سرور برنامه) با پایگاه داده فراتر از محتوای ثابت هستند، ممکن است برنامه‌های وب نیز نامیده شوند. خط بین هر دو نوع تار است.

برنامه های کاربردی تک صفحه ای

ظهور اپلیکیشن های تک صفحه ای (SPA) باعث محبوبیت جاوا اسکریپت شد. اما، قبل از آن، وب‌سایت‌ها عمدتاً با HTML به علاوه CSS و فقط مقداری جاوا اسکریپت ساخته می‌شدند. جاوا اسکریپت کوچک برای انیمیشن ها یا دستکاری های DOM (به عنوان مثال حذف، افزودن، اصلاح عناصر HTML) استفاده شد، اما خیلی فراتر از این نبود. و jQuery یکی از محبوب ترین کتابخانه ها برای انجام چنین کارهایی بود.

اما چه کسی فکر می‌کرد که می‌توان کل برنامه‌ها را با جاوا اسکریپت ساخت؟ تعدادی از کتابخانه ها/فریم ورک های قبلی برای نوشتن برنامه های کاربردی تک صفحه ای در جاوا اسکریپت Knockout.js، Ember.js و Angular.js بودند. در حالی که React.js و Vue.js بعدا منتشر شدند. اکثر آنها تا به امروز در برنامه های کاربردی وب مدرن بسیار فعال هستند.

قبل از برنامه های تک صفحه ای، یک مرورگر فایل HTML و تمام فایل های پیوند شده را از یک وب سرور برای یک وب سایت درخواست می کند. اگر کاربر از یک صفحه (به عنوان مثال /home) به صفحه (مثلا /about) در همان دامنه (مثلا webyar.co) حرکت کند، برای هر پیمایش یک درخواست جدید از وب سرور وجود خواهد داشت.

در مقابل، یک برنامه تک صفحه ای کل برنامه را در اکثراً جاوا اسکریپت کپسوله می کند که تمام دانش در مورد چگونگی و آنچه را که با HTML (و CSS) داخل آن رندر شود، دارد. برای ابتدایی ترین استفاده از یک برنامه تک صفحه ای، مرورگر فقط یک بار یک فایل HTML با یک فایل جاوا اسکریپت پیوند یافته برای دامنه ای که میزبان یک SPA است درخواست می کند.

HTML درخواستی برای یک برنامه تک صفحه ای (در اینجا یک برنامه React) فقط یک واسطه برای درخواست برنامه جاوا اسکریپت است (اینجا bundle.js ) که پس از درخواست در HTML ارائه می شود (اینجا id=\”app\”):

<!DOCTYPE html>
<html>
  <head>
    <title>Hello HTML File which executes a React Application</title>
  </head>
  <body>
    <div id=\"app\"></div>
    <script src=\"./bundle.js\"></script>
  </body>
</html>

از آنجا، React با این جاوا اسکریپت کوچک از یک ./bundle.js و فایل bundle در زیر مشاهده می گردد:

import React from \'react\';
import ReactDOM from \'react-dom\';
const title = \'React with Webpack and Babel\';
ReactDOM.render(
  <div>{title}</div>,
  document.getElementById(\'app\')
);

در این تکه کد کوچک، React تنها یک متغیر به نام title را در یک عنصر div نمایش می دهد. با این حال، همه چیز بین عنصر div را می توان با یک ساختار کامل HTML که با React و سینتکس JSX آن ساخته شده است جایگزین کرد. کد نوشته شده اساساً از موتور قالب قبلی React است، اما فقط به جای سرور روی کلاینت اجرا شده است و بنابراین دیگر رندر سمت سرور نیست.

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

اگر SPA فقط یک بار از یک وب سرور درخواست شود، وقتی کاربر از یک صفحه به صفحه دیگر در همان دامنه (به عنوان مثال webyar.co/about به webyar.co/home) بدون درخواست HTML دیگری حرکت می کند، چگونه کار می کند؟ با استفاده از SPA سنتی، ما همچنین از مسیریابی سمت سرور به مسیریابی سمت سرویس گیرنده حرکت کردیم. فایل جاوا اسکریپت درخواستی اولیه برای SPA پایه دارای تمام صفحات یک وب سایت کپسوله شده است. پیمایش از یک صفحه (به عنوان مثال /about) به صفحه دیگر (مثلا /home) هیچ درخواستی را به سرور وب انجام نمی دهد. در عوض، یک روتر سمت کلاینت (مثلاً React Router برای React) وظیفه ارائه صفحه مناسب از فایل جاوا اسکریپت درخواستی اولیه را بر عهده می گیرد.

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

می توان گفت که قبل از برنامه تک صفحه ای با برنامه های چند صفحه ای کار کرده ایم، زیرا برای هر صفحه (مثلاً /about) یک درخواست جدید از وب سرور برای بازیابی تمام فایل های لازم برای آن ارسال می شود. با این حال، اصطلاح برنامه چند صفحه ای واقعاً یک چیز نیست، زیرا قبل از محبوب شدن برنامه های تک صفحه ای، پیش فرض بود.

توجه: درخواست کل برنامه به‌عنوان فایل جاوا اسکریپت پس از بزرگ‌تر شدن برنامه به یک نقطه ضعف تبدیل می‌شود. برای یک برنامه کاربردی تک صفحه‌ای پیچیده‌تر، از تکنیک‌هایی مانند تقسیم کد استفاده می‌شود تا تنها بخشی از برنامه مورد نیاز صفحه فعلی را ارائه کند (مثلا webyar.co/home). هنگام حرکت به صفحه بعدی، درخواست دیگری از وب سرور برای درخواست قسمتی یا بخشی از صفحه برای این مسیر ارسال می شود و کل صفحه مجددا ارسال نمی گردد.

برنامه های فول استک

اکنون وارد پارادایم اپلیکیشن های فول استک می شویم. یک برنامه فول استک شامل سرویس گیرنده (به عنوان مثال SPA) و برنامه سرور است. وقتی شرکت‌ها به دنبال توسعه‌دهندگان فول استک هستند، اغلب می‌خواهند شخصی را داشته باشند که بتواند برنامه‌های سرویس گیرنده-سرور را در هر دو طرف ایجاد کند. گاهی اوقات کلاینت و سرور زبان برنامه نویسی یکسانی دارند (مثلاً جاوا اسکریپت با React روی کلاینت، جاوا اسکریپت با Node.js روی سرور)، اما مجبور نیستند که از یک تکنولوژی مشترک استفاده نمایند.

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

تا کنون، از وب‌سایت‌های سنتی با HTML/CSS/JavaScript به برنامه‌های کاربردی وب مدرن (مثلاً برنامه‌های React) مهاجرت کردیم. یاد آور می شوم که، ارائه محتوای استاتیک خوب است، اما چگونه می‌توانیم محتوای پویا، به عنوان مثال محتوای خاص کاربر مانند یک پست وبلاگ را ارائه دهیم، اگر فقط جاوا اسکریپت (و کمی HTML) از یک وب سرور به مشتری در هنگام کار با SPA ارائه گردد؟

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

بنابراین، درخواست دیگری از کلاینت به سرور برای درخواست داده های از دست رفته برای پر کردن جاهای خالی روی کلاینت باید ارسال کند. موتور (مبتنی بر جاوا اسکریپت) قالب سمت کلاینت از محتوای درون یابی (داده ها) با ساختار (HTML) مراقبت می کند.

هنگامی که همه چیز در مرورگر ارائه می شود، کاربر شروع به تعامل با برنامه می کند، به عنوان مثال با ایجاد یک پست وبلاگ جدید. JSON یک فرمت ترجیحی برای ارسال داده از کلاینت به سرور و بالعکس است. سرور با تمام درخواست های کلاینت با خواندن یا نوشتن در پایگاه داده سروکار دارد. که می تواند روی همان سرور فیزیکی باشد، اما نیازی به بودن روی همان سرور فیزیکی ندارد (مثلاً روی سرور فیزیکی دیگری مستقر باشد).

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

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

آخرین، اما نه کم اهمیت، رابط بین کلاینت و سرور API نامیده می شود . شما ممکن است با یک نوع خاص از API کار کنید.

ارتباط کلاینت و سرور

برنامه های کاربردی فول استک سنتی از REST به عنوان پارادایم API خود استفاده می کنند. که از روش های HTTP برای عملیات CRUD استفاده می کند. قبلاً از روش‌های HTTP برای عملیات CRUD – بدون پیروی از محدودیت‌های واضح – در میان فایل‌ها و تعاملات کاربر مانند ایجاد یک پست وبلاگ با زبان‌های سمت سرور مانند PHP استفاده می‌کردیم.

با این حال، هنگام استفاده از یک REST API، از این روش‌های HTTP در منابع RESTful استفاده می‌کنیم. به عنوان مثال، یک منبع RESTful می تواند یک پست وبلاگ باشد. کاربر می تواند پست های وبلاگ را با متد GET از سرور برنامه بخواند یا یک پست وبلاگ جدید با متد POST در سرور برنامه ایجاد کند.

REST API برنامه های کاربردی سرویس گیرنده و سرویس دهنده را بدون نیاز به وابستگی به یک زبان برنامه نویسی با هم متصل می کند. آنها فقط باید یک کتابخانه برای ارسال داده ها در قالب HTTP ارائه دهند. REST یک پارادایم ارتباطی است که فاقد قالب داده (اما اغلب JSON خواهید دید) و زبان برنامه نویسی است.

یک جایگزین مدرن برای REST ، استفاده از GraphQL که برای APIهای بین کلاینت ها و سرورها استفاده می شود. GraphQL نیز به فرمت داده محدود نمی شود و بر خلاف REST به HTTP محدود نمی شود، اما اغلب می بینید که HTTP و JSON نیز در اینجا استفاده می شوند.

با فناوری مورد بحث تا این مرحله، برنامه های کاربردی فول استک، برنامه های کاربردی سرویس گیرنده و سرویس دهنده را جدا می کنند. هر دو از طریق یک API به خوبی انتخاب شده (مانند REST یا GraphQL) ارتباط برقرار می کنند. در حالی که برنامه کلاینت همه چیز لازم برای برنامه وب را در مرورگر ارائه می کند، برنامه سرور درخواست های کلاینت برای عملیات خواندن و نوشتن را بررسی و به آنها رسیدگی می کند.

فرانت‌اند و بک اند

ما هنوز در مورد اصطلاحات frontend و backend صحبت نکرده‌ایم، زیرا نمی‌خواستم اطلاعات زیادی را از قبل اضافه کنم. یک برنامه frontend ممکن است همه چیزهایی باشد که کاربر در مرورگر می بیند (به عنوان مثال وب سایت، برنامه وب، SPA). از این رو می بینید که توسعه دهندگان فرانت اند اغلب با HTML/CSS یا یک کتابخانه سمت کلاینت مانند React.js کار می کنند. در مقابل، backend اغلب منطق پشت صحنه است: منطقی است که از پایگاه داده می خواند و می نویسد، منطقی است که با برنامه های کاربردی دیگر صحبت می کند، و اغلب منطقی است که یک API ارائه می دهد.

هر دو موجودیت منجر به معماری کلاینت-سرور (رابطه فرانت‌اند و بک) می‌شوند، در حالی که backend برای منطق تجاری (A) مورد نیاز است که نباید به عنوان کد منبع در معرض برنامه فرانت‌اند قرار گیرد (در غیر این صورت توسط مرورگر قابل دسترسی خواهد بود.) یا برای (B) ایجاد اتصالات حساس به منابع داده شخص ثالث (به عنوان مثال پایگاه داده(ها)).

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

اما، در مقابل، اصطلاحات کلاینت و سرور یک دیدگاه هستند. مثلا، یک برنامه پشتیبان (بک اند 1) که یک برنامه کاربردی دیگر (بک اند 2) را استفاده می کند، به یک برنامه کلاینت (بک اند 1) برای برنامه سرور (بک اند 2) تبدیل می شود. در نتیجه ، همان برنامه پشتیبان (بک اند 1) همچنان سرور یک برنامه کلاینت دیگر است که فرانت اند محسوب می شود.

اگر می‌خواهید به سؤال کلاینت-سرور پاسخ دهید، اگر کسی از شما می‌پرسد که یک موجودیت چه نقشی در معماری مشتری-سرور دارد، همیشه از خود بپرسید که چه کسی (سرور) به چه کسی (کلاینت) خدمات می‌دهد و چه کسی (سرویس‌گیر) عملکردهای چه کسی (بک‌اند) را مصرف می‌کند؟

میکرو سرویس (اختیاری)

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

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

Backend-As-A-Service (اختیاری)

در مفهوم سنتی، یک برنامه کاربردی بک اندکه فقط برای سرویس دهی به یک برنامه کاربردی وجود دارد، اغلب به یک پایگاه داده متصل می شود. پس یک برنامه معمولی فول استک خواهد بود. با این حال، اغلب برنامه های کاربردی پشتیبان کار زیادی انجام نمی دهند به جز خواندن و نوشتن در یک پایگاه داده، اجازه دادن به کاربران خاص برای انجام برخی اقدامات (مجوز دادن)، یا احراز هویت (مثلا ورود، خروج، ثبت نام) کاربر در مرحله اول. در این موارد، اغلب نیازی به پیاده‌سازی یک برنامه پشتیبان در موقعیت مکانی نزدیک به خودتان نیست.

Firebase، یک راه حل برای یک بک اند به عنوان یک سرویس، یک پایگاه داده، احراز هویت و مجوز را به عنوان یک بک اند خارج از حیطه کاری شما ارائه می دهد. از این رو، یک توسعه‌دهنده تنها با اجرای برنامه فرانت اند (مثلاً برنامه React) باقی می‌ماند که باید به عنوان یک سرویس بک اند ارتباط برقرار می کند.

یک بک‌اند به‌عنوان سرویس (BAAS) مانند Firebase به توسعه‌دهندگان اجازه می‌دهد تا برنامه‌های فرانت‌اند خود را خیلی سریع راه‌اندازی کنند. همه چیز از احراز هویت، مجوز و پایگاه داده برای شما انجام می شود. علاوه بر این، اکثر BAAS هاستینگ را نیز ارائه می دهند، برای مثال برنامه React شما می تواند با Firebase نیز میزبانی شود. بنابراین Firebase برنامه React شما را به سرویس گیرنده (مرورگر) شما ارسال می کند و برنامه شما را قادر می سازد تا برای تمام ویژگی های دیگر (به عنوان مثال پایگاه داده) با هاست Firebase ارتباط برقرار کند.

فراتر از برنامه های فول استک

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

• رندر سمت سرور (X) به رندر سمت کلاینت (Y)
• مسیریابی سمت سرور (X) به مسیریابی سمت سرویس گیرنده (Y)

در ادامه، می‌خواهیم دو رویکرد را به شما معرفی کنم که فلسفه‌های آنها (SSR، SSG) جدید نیستند، اما در صورت استفاده با کتابخانه‌های مدرن (مانند React) و سایر چارچوب‌ها (مانند Next.js، Gatsby.js) بسیار قدرتمند هستند. که این رویکردها را ممکن می سازد.

رندر سمت سرور 2.0 (SSR)

ما قبلاً در مورد رندر سمت سرور برای وب 2.0 صحبت کردیم. پس از آن، برنامه های فول استک کلاینت و سرور را از هم جدا کردند و رندر سمت کلاینت را با کتابخانه هایی مانند React انجام دادند. پس یک قدم به عقب برگردیم و از React برای رندر سمت سرور استفاده کنیم؟

هنگام استفاده از چارچوب محبوب Next.js که در بالای React قرار دارد، همچنان در حال توسعه برنامه های React هستید. با این حال، هر چیزی که در Next.js پیاده‌سازی می‌کنید React در سمت سرور رندر می‌شود. در Next.js، شما هر صفحه (به عنوان مثال /about یا /home) را با React پیاده سازی می کنید. هنگامی که کاربر از صفحه ای به صفحه دیگر حرکت می کند، تنها بخشی از React ارائه شده در سمت سرور به مرورگر ارسال می شود.

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

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

طراحی سایت استاتیک (SSG)

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

React در باطن برای فایل های ثابت ساخته نشده است. در عوض، React فقط فایل‌های جاوا اسکریپت است که برنامه را به سرعت در سمت کلاینت ایجاد می‌کند. با این حال، Gatsby.js، چارچوبی که در بالای React قرار دارد، برای تولید سایت استاتیک برای برنامه‌های React استفاده می‌کند. Gatsby.js یک برنامه React را می گیرد و آن را در فایل های ثابت کامپایل می کند. سپس همه این فایل ها را می توان بر روی یک وب سرور میزبانی کرد. اگر کاربر از یک URL بازدید کند، فایل های ثابت به مرورگر ارائه می شود.

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