آشنایی با شیوه طراحی وب‌ اپلیکیشن – راهنمای کاربردی

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

• معماری نرم‌افزار چیست؟
• چرا معماری نرم‌افزار مهم است؟
• تفاوت بین معماری نرم‌افزار و طراحی نرم‌افزار چیست؟
• الگوهای معماری نرم‌افزار کدام هستند؟
• تعداد بخش‌های نرم‌افزار چند عدد باید باشد؟
• کدامیک از گزینه‌های مقیاس‌بندی افقی با عمودی برای شما مناسب‌تر است؟
• معماری Monolith یا میکرو سرویس؟
• چه زمانی باید از SQL یا NoSQL استفاده کرد؟
• فناوری مناسب برای هر کار کدام است؟
• چگونه معمار نرم‌افزار شویم؟
• سخن پایانی

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

معماری نرم‌افزار چیست؟

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

برخی نکات کلیدی در خصوص این معماری نرم‌افزار به شرح زیر هستند:

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

یکی از تعاریف محبوب از معماری نرم‌افزار متعلق به «رالف جانسون» (Ralph Johnson) و به صورت زیر است:

«معماری نرم‌افزار مربوط به تصمیم‌هایی است که آرزو می‌کنید در مراحل نخستین پروژه اتخاذ می‌کردید.»

چرا معماری نرم‌افزار مهم است؟

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

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

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

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

توسعه نرم‌افزار یک فرایند تکراری و تکاملی است. هیچ چیز در لحظه نخست کامل نیست. اما این مسئله توجیهی برای احتراز از تمرین و کار مداوم محسوب نمی‌شود.

تفاوت بین معماری نرم‌افزار و طراحی نرم‌افزار

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

معماری نرم‌افزار برای تعریف چارچوب و کامپوننت‌های سطح بالای یک سیستم و شیوه همکاری آن‌ها با یکدیگر مورد استفاده قرار می‌گیرد. برای نمونه باید تصمیم بگیریم آیا به یک معماری بدون سرور نیاز داریم که اپلیکیشن را به دو کامپوننت BAAS یعنی «بک‌اند به عنوان سرویس» (backend-as-a-service) یا FaaS یعنی «کارکرد به عنوان سرویس» (functions-as-a-service) تقسیم می‌کند؟ یا این که باید چیزی مانند یک معماری میکرو سرویس داشته باشیم که قابلیت‌ها و وظایف مختلف در ماژول‌ها و کدبیس‌های متفاوت قرار گیرند.

انتخاب معماری به مواردی از قبیل عملکرد، تحمل خطا، ‌مقیاس‌پذیری و پایداری مرتبط است.

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

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

برای کسب اطلاعات بیشتر در این خصوص پیشنهاد می‌کنیم به آموزش ویدیویی زیر زیر مراجعه کنید:

• آموزش مهندسی نرم‌افزار ۱

الگوهای معماری نرم‌افزار

در این بخش در مورد الگوهای مختلفی که برای معماری نرم‌افزار وجود دارند، توضیحاتی ارائه می‌کنیم.

کلاینت-سرور

این معماری بر مبنای مدل درخواست-پاسخ کار می‌کند. کلاینت درخواست برای اطلاعات را به سرور ارسال می‌کند و سرور به آن پاسخ می‌دهد.

هر وب‌سایتی که بازدید می‌کنید، ‌چه یک وبلاگ وردپرسی باشد و چه یک وب‌اپلیکیشن مانند فیسبوک یا توییتر و یا حتی اپلیکیشن اینترنت بانک باشد، ‌بر مبنای معماری کلاینت-سرور بنا شده است.

همتا به همتا

یک شبکه Peer-to-Peer یا به اختصار P2P به شبکه‌ای گفته می‌شود که در آن رایانه‌ها که به نام «گره» (‌Node) ‌نیز نامیده می‌شوند، ‌می‌توانند بدون نیاز به یک سرور مرکزی با هم ارتباط بگیرند. عدم وجود سرور مرکزی، امکان وجود «نقطه شکست منفرد» را از بین می‌برد. همه رایانه‌ها در این شبکه دارای حقوق برابری هستند. هر گره می‌تواند به صورت همزمان به عنوان یک seeder و leecher عمل کند. بنابراین حتی اگر برخی رایانه‌ها یا گره‌های شبکه خاموش شوند، شبکه و ارتباط همچنان برقرار خواهد بود.

معماری P2P مبنای فناوری بلاک چین را تشکیل می‌دهد.

معماری مدل-ویو-کنترلر (MVC)

معماری Model-View-Controller یا به اختصار MVC به آن الگوی معماری نرم‌افزار گفته می‌شود که منطق اپلیکیشن را بر مبنای کارکردهایشان به سه مؤلفه تقسیم می‌کند. این مؤلفه‌ها شامل موارد زیر هستند:

• مدل- شیوه ذخیره داده‌ها را در پایگاه داده مشخص می‌سازد.
• نما (View) - کامپوننت‌هایی که در دید کاربر هستند مانند خروجی یا GUI را شامل می‌شود.
• کنترلر- کامپوننت‌هایی که به عنوان یک اینترفیس بین مدل و نما عمل می‌کنند را شامل می‌شود.

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

میکرو سرویس

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

رویداد-محور

یک معماری غیر مسدودساز است که به نام معماری واکنشی یا «رویداد-محور» (Event-driven) نیز شناخته می‌شود. معماری‌های رویداد-محور در توسعه وب‌اپلیکیشن‌های مدرن بسیار رایج هستند.

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

لایه‌بندی ‌شده

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

لایه‌های متداول‌تر به شرح زیر هستند:

• لایه ارائه
• لایه اپلیکیشن
• لایه منطق کسب و کار
• لایه دسترسی به داده

پنج‌ ضلعی

این معماری شامل سه مؤلفه است:

• پورت
• آداپتر
• دامنه

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

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

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

• آموزش مدل‌های فرایند در مهندسی نرم‌افزار

تعداد بخش‌های اپلیکیشن چند عدد باید باشد؟

امکان طراحی اپلیکیشن با بخش‌های (Tires) ‌مختلف وجود دارد که از اپلیکیشن‌ها تک‌بخشی تا چند بخشی را شامل می‌شود. در این بخش در مورد مزایا و معایب هر کدام این موارد صحبت می‌کنیم.

اپلیکیشن‌های تک‌بخشی

اپلیکیشن‌های تک‌بخشی مزیت‌ها و معایبی به شرح زیر دارند:

مزایا

• تأخیر شبکه وجود ندارد.
• داده‌ها به سرعت و سهولت در اختیار ما قرار می‌گیرند.
• داده‌ها روی شبکه منتقل نمی‌شوند و به این ترتیب امنیت داده‌ها تضمین می‌شود.

معایب

• کنترل کمی روی اپلیکیشن وجود دارد. پیاده‌سازی قابلیت‌های جدید و تغییر کد پس از انتشار آن دشوار است.
• تست کد باید پوشش کامل داشته باشد و جایی برای بروز اشتباه وجود ندارد.
• اپلیکیشن‌های تک‌بخشی در معرض آسیب دستکاری و مهندسی معکوس هستند.

اپلیکیشن‌های دو بخشی

• در این بخش مزایا و معایب اپلیکیشن‌های دوبخشی را بررسی می‌کنیم.

مزایا

• فراخوانی‌های شبکه کمتر است زیرا کد و UI روی دستگاه یکسانی هستند.
• سرور پایگاه داده و منطق کسب و کار از نظر فیزیکی به هم نزدیک هستند و عملکرد بالاتری فراهم می‌آید.

معایب

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

اپلیکیشن‌های سه ‌بخشی

• در این بخش مزایا و معایب اپلیکیشن‌های سه‌بخشی را بررسی می‌کنیم.

مزایا

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

معایب

• به طور معمول در این معماری باید تلاش بیشتری انجام گیرد، زیرا نقاط ارتباطی (کلاینت به بخش میانی به سرور؛‌به جای ارتباط مستقیم کلاینت-سرور) ‌افزایش می‌یابند و عملکردی که به وسیله ابزارهایی از قبیل Visual Basic, PowerBuilder و Delphi افزایش یافته بود، کاهش خواهد یافت.

اپلیکیشن‌های N-بخشی

• در این قسمت مزایا و معایب اپلیکیشن‌های N-بخشی را بررسی می‌کنیم.

مزایا

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

معایب

• به دلیل کامپوننتی شدن بخش‌ها، ساختار پیچیده‌ای پدید می‌آید که پیاده‌سازی و نگهداری آن دشوار است.

جمع‌بندی

• زمانی که می‌خواهید هیچ تأخیر شبکه‌ای در نرم‌افزار شما وجود نداشته باشد، ‌باید از معماری تک‌بخشی استفاده کنید.
• زمانی که نیاز دارید تأخیر شبکه را در کمترین حد ممکن نگهدارید و همچنین روی داده‌های درون اپلیکیشن کنترل داشته باشید، باید از معماری دوبخشی استفاده کنید.
• زمانی که باید کنترل بیشتری روی کد یا منطق کسب‌وکار اپلیکیشن خود داشته باشید و می‌خواهید امنیت آن بالاتر باشد و ایمنی داد‌ها افزایش یابد، باید از معماری سه‌بخشی استفاده کنید.
• در مواردی که نیاز است اپلیکیشن مقیاس‌پذیری داشته باشد و حجم بالایی از داده‌ها را مدیریت کند باید از معماری N-بخشی استفاده کنید.

کدام یک از گزینه‌های مقیاس‌بندی افقی یا عمودی برای شما مناسب‌تر است؟

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

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

این اپلیکیشن‌های باید روی کلود توزیع شوند و مقیاس‌پذیری افقی از همان ابتدا در نظر گرفته شود.

معماری Monolith یا Microservice؟

در این بخش به بررسی دو معماری مونولیتیک و میکرو سرویس و کاربردهای هر کدام می‌پردازیم.

چه زمانی باید از معماری Monolith استفاده کنیم؟

اپلیکیشن‌های مونولیتیک در مواردی بهترین کاربرد را دارند که الزامات کار ساده هستند و انتظار می‌رود که اپلیکیشن حجم محدودی از ترافیک را مدیریت کند. برای نمونه یک اپلیکیشن محاسبه مالیات برای یک سازمان یا ابزار عمومی مشابه چنین حالتی دارد.

برخی کاربردها وجود دارند که یک کسب و کار مطمئن است که نرم‌افزار مورد نظرش در طی زمان رشد نمایی در تعداد کاربران و ترافیک نخواهد داشت.

همچنین مواردی هستند که تیم‌های توسعه تصمیم می‌گیرند تا کار را با معماری مونولیتیک آغاز کنند و سپس با معماری میکرو سرویس توزیع‌یافته آن را ادامه دهند. بدین ترتیب پیچیدگی اپلیکیشن به صورت گام به گام و در موارد نیاز افزایش می‌یابد. این دقیقاً کاری است که LinkedIn انجام داده است.

چه زمانی باید از معماری میکرو سرویس استفاده کنیم؟

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

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

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

• انتخاب یک معماری مونولیتیک.
• انتخاب یک معماری میکرو سرویس.
• آغاز کار با معماری مونولیتیک و سپس مقیاس‌پذیری متعاقب به معماری میکرو سرویس.

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

باید از SQL یا NoSQL استفاده کنیم؟

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

چه زمانی باید از پایگاه‌های داده SQL استفاده کنیم؟

اگر مشغول نوشتن یک اپلیکیشن در مورد خرید و فروش سهام، بانکداری و یا مرتبط با امور مالی هستید و یا می‌خواهید روابط زیادی را ذخیره کنید، ‌برای نمونه یک شبکه اجتماعی مانند فیسبوک طراحی می‌کنید، ‌در این صورت باید از «پایگاه داده رابطه‌ای» (relational database) ‌استفاده کنید. دلیل این را در بخش بعدی توضیح می‌دهیم.

تراکنش‌ها و موضوع انسجام داده‌ها

اگر نرم‌افزاری می‌نویسید که هر نوع ارتباطی با پول یا اعداد دارد، بنابراین تراکنشی را ثبت می‌کند و باید با ACID سازگار باشد. در این حالت موضوع انسجام داده‌ها برای شما بسیار مهم است. پایگاه‌های داده رابطه‌ای برای اجرای تراکنش‌ها و حفظ انسجام داده‌ها عملکرد خوبی دارند، چون با اصول ACID سازگار هستند و ‌تجربه خود را در این زمینه به خوبی پس داده‌اند.

ذخیره روابط

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

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

• MySQL
• Microsoft SQL Server
• PostgreSQL
• MariaDB

چه زمانی باید از پایگاه داده NoSQL استفاده کنیم؟

دلایل مختلفی برای انتخاب یک پایگاه داده NoSQL وجود دارد که در ادامه آن‌ها را شرح می‌دهیم.

مدیریت تعداد بالایی از عملیات خواندن-نوشتن

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

اجرای آنالیز داده‌ها

پایگاه‌های داده NoSQL بهترین گزینه برای آنالیز داده‌ها هستند، ‌چون می‌توانند با حجم عظیمی از داده‌ها سروکار داشته باشند. فهرست پایگاه‌‌های داده NoSQL محبوب به شرح زیر است:

• MongoDB
• Redis
• Cassandra
• HBASE

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

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

تعامل با داده‌های همزمان

اگر اپلیکیشنی می‌خواهید که دارای خصوصیات زیر است:

• با سرور بک‌اند به صورت همزمان کار می‌کند و کارکردی شبیه اپلیکیشن پیام‌رسانی یا اپلیکیشن پخش صوت-ویدئو مانند اسپاتیفای یا نتفلکیس و غیره است.
• یک اتصال مداوم بین کلاینت و سرور برقرار است و فناوری غیر مسدودساز در بک‌اند مورد نیاز است.

در این صورت برخی از فناوری‌های متداول که امکان نوشتن چنین اپلیکیشن‌های را فراهم می‌سازند شامل NodeJS و فریمورک محبوب پایتون به نام Tornado هستند.

وب‌اپلیکیشن همتا به همتا

اگر می‌خواهید یک وب‌اپلیکیشن همتا به همتا برای مثال یک موتور جستجوی توزیع‌یافته P2P یا یک سرویس رادیو تلویزیون زنده P2P بنویسید که احتمالاً مشابه LiveStation از مایکروسافت باشد، در این صورت باید از برخی پروتکل‌های جاوا اسکریپت از قبیل DAT یا IPFS استفاده کنید. FreedomJS (+) یک فریمورک برای ساخت وب‌اپلیکیشن‌های P2P است که روی مرورگرهای وب مدرن کار می‌کند.

اپلیکیشن معمولی بر مبنای CRUD

اگر اپلیکیشن شما کاربردهای ساده از قبیل یک اپلیکیشن بر مبنای CRUD دارد، برخی از فناوری‌ها از قبیل Spring MVC ،Python Django ،Ruby on Rails ،PHP Laravel و ASP.NET MVC وجود دارند که می‌توانید مورد استفاده قرار دهید.

اپلیکیشن‌های ساده و با مقیاس کوچک

اگر می‌خواهید اپلیکیشنی بنویسید که پیچیدگی چندانی ندارد، مثلاً یک بلاگ یا یک فرم آنلاین ساده یا یک اپلیکیشن ساده است که با یک رسانه اجتماعی درون یک Iframe پورتال ادغام می‌شود، می‌توانید از PHP استفاده کنید. همچنین می‌توانید از فریمورک‌های وب دیگر مانند Spring boot و Ruby on Rails استفاده کنید که حجم کد کمتری دارند و الزامات پیکربندی و زمان توسعه را کاهش داده و موجب تسهیل توسعه سریع می‌شوند. اما میزبانی PHP در قیاس با دیگر فناوری‌های میزبانی هزینه به مراتب کمتری دارد و برای کاربردهای ساده مناسب است.

اپلیکیشن‌های با مصرف CPU و حافظه بالا

در برخی موارد نیز لازم است که وظایف محاسباتی با مصرف بالای CPU و حافظه در بک-اند اجرا کنیم. برای نمونه ممکن است لازم باشد پردازش کلان داده، ‌پردازش موازی و یا نظارت و تحلیلی روی حجم بالایی از داده‌ها اجرا کنیم.

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

• آموزش برنامه‌نویسی C++‎

Rust یک زبان برنامه‌نویسی مشابه C++ است. این زبان برای عملکرد بالا و همزمانی ایمن طراحی شده است. این زبان اخیراً در میان توسعه‌دهندگان محبوبیت زیادی کسب کرده است. جاوا، اسکالا و گو نیز زبان‌های خوبی به این منظور هستند. اغلب سیستم‌های سازمانی با مقیاس بزرگ با جاوا نوشته می‌شوند.

Go یک زبان برنامه‌نویسی است که از سوی گوگل برای نوشتن اپلیکیشن‌هایی برای ماشین‌های چندهسته‌ای و مدیریت حجم بالایی از داده‌ها طراحی شده است. برای کسب اطلاعات بیشتر در مورد این زبان پیشنهاد می‌کنیم از آموزش زیر استفاده کنید:

• آموزش توسعه وب با زبان برنامه‌نویسی Go

«جولیا» (Julia) نیز یک زبان برنامه‌نویسی دینامیک است که برای عملکرد بالا و اجرای محاسبات و آنالیز عددی طراحی شده است.

چگونه یک معمار نرم‌افزار شویم؟

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

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

شما به عنوان یک معمار نرم‌افزار خبره باید به طور مداوم دانش‌تان را در زمینه جدیدترین روندهای این حوزه بهبود ببخشید. احتمالاً باید کار خود را با یادگیری یک یا چند زبان برنامه‌نویسی آغاز کنید و به عنوان یک توسعه‌دهنده نرم‌افزار کار کنید و به تدریج راه خود را بیابید.

با این که امکان اخذ مدرک معماری نرم‌افزار در دانشگاه وجود ندارد، اما برخی دوره‌های آموزشی وجود دارند که می‌توانند به یادگیری این رشته کمک کنند.

سخن پایانی درباره طراحی وب‌ اپلیکیشن

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

اگر این مطلب برای شما مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:

• مجموعه آموزش‌‌های دروس علوم و مهندسی کامپیوتر
• مجموعه آموزش‌های برنامه‌‌نویسی
• آموزش طراحی الگوریتم
• ۱۱ قدم برای تبدیل شدن به مهندس نرم‌افزار
• معرفی رشته مهندسی کامپیوتر — از تحصیل تا اشتغال

==