معماری صحیح وب سایت؛ چگونه سایتی بسازیم که با رشد کسب و کار دوباره مجبور به بازطراحی نشود؟
بسیاری از پروژه های وب با یک نیاز ساده شروع می شوند.
یک شرکت به یک سایت معرفی نیاز دارد، یک فروشگاه تصمیم می گیرد فروش آنلاین خود را راه اندازی کند یا یک مجموعه خدماتی می خواهد امکان ثبت درخواست را در اختیار مشتریان قرار دهد.
در شروع پروژه، معمولا همه چیز ساده به نظر می رسد.
اما چند ماه بعد تعداد کاربران افزایش پیدا می کند، اطلاعات بیشتر می شود، امکانات جدید مورد نیاز قرار می گیرند و ارتباط سایت با سرویس های دیگر ضروری می شود.
در این مرحله یک سوال مهم مطرح می شود:
آیا سایت برای رشد ساخته شده است؟
معماری وب سایت یعنی چه؟
معماری را می توان نقشه فنی و منطقی سیستم دانست.
این معماری مشخص می کند بخش های مختلف سایت چگونه با یکدیگر ارتباط دارند، داده ها چگونه ذخیره و منتقل می شوند، کاربران چگونه احراز هویت می شوند، Front-end چگونه با Backend ارتباط برقرار می کند و سیستم چگونه می تواند در آینده امکانات جدید را بپذیرد.
معماری خوب لزوما پیچیده نیست.
برعکس، یکی از نشانه های معماری مناسب این است که پیچیدگی فقط در جایی وجود داشته باشد که واقعا لازم است.
اشتباه رایج؛ طراحی برای امروز
یکی از اشتباهات رایج این است که تمام تصمیمات بر اساس نیاز فعلی گرفته شوند.
فرض کنید یک مجموعه امروز فقط ۱۰۰۰ محصول دارد. ممکن است ساختاری که برای این حجم اطلاعات مناسب است، در آینده با ۱۰۰ هزار محصول عملکرد مناسبی نداشته باشد.
یا ممکن است یک سیستم ابتدا فقط برای یک مدیر طراحی شود، اما چند ماه بعد به چند سطح دسترسی، چند اپراتور و پنل های متفاوت نیاز پیدا کند.
این به معنی آن نیست که باید از روز اول یک سیستم بسیار پیچیده طراحی کرد.
راهکار صحیح، طراحی متناسب با نیاز فعلی همراه با در نظر گرفتن مسیرهای منطقی توسعه آینده است.
دیتابیس؛ جایی که بسیاری از مشکلات از آن شروع می شوند
در سیستم های اطلاعاتی، طراحی دیتابیس اهمیت بسیار زیادی دارد.
نامناسب بودن روابط بین جداول، نبود Indexهای ضروری، Queryهای سنگین یا ذخیره سازی نادرست اطلاعات می تواند با افزایش حجم داده ها به یک مشکل جدی تبدیل شود.
ممکن است سایتی با ۱۰۰۰ رکورد بدون مشکل کار کند اما پس از افزایش اطلاعات، زمان پاسخگویی آن به شکل محسوسی افزایش پیدا کند.
بنابراین طراحی دیتابیس نباید فقط بر اساس این سوال باشد که «امروز چه اطلاعاتی داریم؟»
باید پرسید:
این اطلاعات چگونه جستجو خواهند شد؟
چه روابطی میان آنها وجود دارد؟
چه داده هایی بیشتر خوانده می شوند؟
کدام بخش ها دائما تغییر می کنند؟
و اگر حجم اطلاعات چند برابر شد، آیا ساختار فعلی همچنان قابل استفاده خواهد بود؟
API؛ پل ارتباطی بخش های مختلف سیستم
در پروژه های مدرن، بخش های مختلف یک سیستم ممکن است از طریق API با یکدیگر ارتباط داشته باشند.
وب سایت، اپلیکیشن موبایل، پنل مدیریت و حتی نرم افزارهای خارجی می توانند از یک Backend مشترک استفاده کنند.
اگر API از ابتدا با ساختار مشخص، احراز هویت مناسب، کنترل دسترسی، مدیریت خطا و مستندسازی صحیح طراحی شود، توسعه بخش های جدید در آینده آسان تر خواهد بود.
این موضوع مخصوصا برای کسب و کارهایی اهمیت دارد که احتمال توسعه اپلیکیشن یا اتصال به سرویس های دیگر را دارند.
امنیت نباید یک مرحله پایانی باشد
یکی دیگر از اشتباهات رایج این است که امنیت را پس از اتمام پروژه بررسی کنیم.
امنیت باید از همان زمان طراحی سیستم مورد توجه قرار گیرد.
مدیریت نشست کاربران، سطح دسترسی، اعتبارسنجی ورودی ها، محافظت از اطلاعات حساس، کنترل درخواست های API، مدیریت رمزهای عبور و به روزرسانی وابستگی های نرم افزاری، بخشی از چرخه توسعه هستند.
هیچ معماری را نمی توان صرفا با اضافه کردن یک ابزار امنیتی در انتهای پروژه کاملا ایمن کرد.
امنیت باید در لایه های مختلف سیستم در نظر گرفته شود.
معماری باید با سئو نیز هماهنگ باشد
ساختار فنی یک سایت روی نحوه درک صفحات توسط موتورهای جستجو نیز اثر دارد.
ساختار URL، معماری دسته بندی ها، لینک های داخلی، صفحات تکراری، Canonical، Sitemap، وضعیت Index شدن و نحوه تولید صفحات پویا از جمله مواردی هستند که بهتر است هنگام طراحی معماری سایت مورد توجه قرار گیرند.
وقتی ساختار سایت بعدا و بدون برنامه تغییر کند، اصلاح URLها و ارتباط صفحات می تواند هزینه بیشتری ایجاد کند و حتی روی سابقه سئوی سایت تاثیر بگذارد.
چه زمانی باید به Scalability فکر کنیم؟
مقیاس پذیری به این معنی نیست که از همان روز اول یک سایت را برای میلیون ها کاربر طراحی کنیم.
Scalability یعنی سیستم به شکلی طراحی شود که در صورت افزایش منطقی بار، بتوان آن را توسعه داد.
برای یک پروژه کوچک شاید یک معماری ساده کاملا کافی باشد.
اما اگر پروژه قرار است تبدیل به یک پلتفرم بزرگ، فروشگاه گسترده، سامانه رزرو یا سرویس پرترافیک شود، باید از ابتدا محدودیت های معماری ساده را شناخت.
این همان نقطه ای است که تجربه تیم توسعه اهمیت پیدا می کند؛ زیرا انتخاب فناوری باید براساس مسئله واقعی انجام شود، نه صرفا براساس محبوب بودن یک تکنولوژی.
تکنولوژی هدف نیست
در بازار توسعه وب، دائما فناوری های جدید معرفی می شوند.
Framework جدید، زبان جدید، دیتابیس جدید و ابزارهای جدید ممکن است در یک پروژه بسیار مناسب باشند و در پروژه دیگری انتخاب درستی نباشند.
ما معتقدیم تکنولوژی باید در خدمت پروژه باشد.
اول باید مسئله، نیازهای کسب و کار، حجم اطلاعات، تعداد کاربران، امکانات مورد نیاز و مسیر توسعه مشخص شود و سپس درباره فناوری مناسب تصمیم گیری شود.
استفاده از تکنولوژی جدید به خودی خود یک مزیت نیست؛ انتخاب درست تکنولوژی برای مسئله درست اهمیت بیشتری دارد.
بازطراحی نباید اولین راه حل برای هر مشکل باشد
گاهی اوقات با افزایش مشکلات فنی، پیشنهاد می شود کل سایت از ابتدا بازنویسی شود.
در بعضی پروژه ها بازنویسی کامل واقعا منطقی است، اما همیشه چنین نیست.
قبل از تصمیم گیری باید مشخص شود مشکل از کدام بخش ناشی می شود.
ممکن است با اصلاح دیتابیس، بازطراحی یک API، بهینه سازی Front-end، تغییر ساختار Cache یا اصلاح یک بخش از معماری بتوان مشکل را حل کرد.
تصمیم گیری فنی باید بر اساس تحلیل سیستم موجود انجام شود، نه صرفا بر اساس این تصور که «نسخه جدید حتما بهتر است».
یک وب سایت خوب باید برای آینده آماده باشد
هدف از معماری صحیح این نیست که آینده را به طور کامل پیش بینی کنیم؛ چنین کاری عملا ممکن نیست.
هدف این است که سیستم به اندازه کافی منظم، قابل فهم و قابل توسعه ساخته شود تا تغییرات آینده تبدیل به بحران نشوند.
یک وب سایت حرفه ای باید بتواند با رشد کسب و کار رشد کند.
افزایش محصولات، کاربران، محتوا، خدمات و امکانات نباید هر بار به معنی شروع یک پروژه از صفر باشد.
به همین دلیل، ما معماری وب سایت را یکی از مهم ترین بخش های پروژه می دانیم؛ بخشی که ممکن است کاربر نهایی آن را نبیند، اما تاثیر آن در تمام عمر سیستم قابل مشاهده خواهد بود.