Api و Web service
Api و Webservice مانند پل ارتباط هستند. تفاوت آنها در این است که وب سرویس ارتباط بین دو ماشین ( غالباً سرور و کلاینت ) را تسهیل میکند. اما Api مانند یک اینترفیس بین دو اپلیکیشن ( بک و فرانت ) عمل میکند. Api یک روش است تا third-party ها بتوانند به آن متصل و از خدمات ما بهره مند شوند. یک وبسرویس طراحی میشود تا یک اینترفیس داشته باشد، این اینترفیس عموما با یک زبان قابل فهم برای ماشین شرح داده میشود ( WSDL ).
HTTP پرکاربرد ترین پروتکل برای ارتباطات است. وب سرویسها از SOAP, REST, XML-RPG استفاده میکنند.
َبه متدهای یک نرم افزار برای ارتباط با نرم افزارهای دیگر Api میگویند. وقتی که این عمل در بستر وب اتفاق می افتد؛ وب سرویس ها به میدان می آیند.
Api عموماً شامل صداکردن توابع درون نرم افزار میشود.
خلاصه :
همه وب سرویس ها api هستند اما همه apiها وب سرویس نیستند
وب سرویس همه اعمالی که api قادر به انجام آن هست را انجام نمیدهد
وب سرویس فقط در سه بستر قابل اجراست . SOAP, REST, XML-RPG
وب سرویس برای اجرا شدن همواره به شبکه نیاز دارد اما api خیر
مقدمه
در این پست بحث میکنیم که دیتابیس های NoSql چه فرقی با دیتابیس‌های سنتی رابطه‌ای و Schema Base دارند.
همچنین چند راهکار برای مدل کردن دیتابیس نوسکوئل ارائه میشود؛ دیتابیس های داکیومنت بیس بعضاً Schema Less نامیده میشوند که این عبارت نادرست میباشد. این گونه دیتابیس‌ها به ساختار‌های از پیش تعریف شده همانند آنچه در دیتابیس‌های رابطه‌ای داریم نیازی ندارند اما شما باید تعریف کنید که چگونه میخواهید دیتای خود را سازماندهی کنید.
معمولا در NoSql شما قصد دارید تا دیتای خود را به صورت تجمیع شده در اختیار داشته باشید، بنابراین میتوانید دیتای خود را به سرعت و بدون استفاده از Joinها بازیابی کنید. یک دیزاین مناسب از دیتابیس میتواند در نحوه عملکرد برنامه شما تغییرات بسیار زیادی ایجاد کند.
یک حکایت وجود دارد که اگر یک راه حل برای یک مشتری کار میکند با یک ساعت گفتگو 1000 برابر سریع تر کار خواهد کرد!
میخواهم درباره یک مهاجرت بزرگ صحبت کنم. وقتی که با م کارفرمای یکی از پروژه ها تصمیم به بازسازی سرویس گرفتیم.
سرویس مورد نظر یک سرویس ختم گروهی قرآن بود که بیش از 2000 ختم در آن انجام شده بود یعنی چیزی حدود 3 میلیون رکورد ثبت شده برای هر صفحه.
سرویس ابتدا با pure php و بدون فریمورک نوشته شده بود. یک api که با app ارتباط برقرار میکرد و یک ربات تلگرام که مستقیا به دیتابیس وصل میشد!
فاجعه!
قطعاً نمیتوانید همچین چیزی بزنید جز آنکه یک بی تجربه به تمام معنا باشید.
دیتابیس پروژه mysql بود و کاملاً غیراصولی نوشت شده بود.
یک سری از استانداردهای طراحی پایگاه داده کلا رعایت نشده بود و همیشه مجبور به repair کردن جداول بودیم.
حتی از بی تجربگیم میتونم بگم که یک کران جاب طراحی کرده بودم تا هر دو روز یکبار، یکبار همه جداول رو repair کنه
اما به اینجا ختم نمیشد
هیچکدوم از کلاینت های دیتابیس بسته نمیشدند و عملا به حال خودشون رها شده بودند در نتیجه توی رم سرور با فاجعه رو به رو بودید.
وقتی که رممون رو از 512 به 1 و بعد از 1 به 2 ارتقا دادیم و همچنان بیش از 90 درصد رم مشغول بود ( البته که تعداد کاربرها و سرویس ها هم در حال افزایش بود )
توی پیک شلوغی مخصوصا ماه های رمضون اوضاع کاملا به هم میریخت. عنان کار از دت میرفت . گهگاه موقع سحر با کابوس یا اس ام اس کارفرمام از خواب بیدار میشدم تا مشکل رو حل کنم.
یک بخشی از ربات بود که به کاربرایی که علاقه داشتن یک تایم از روز یک صفحه از قرآن میفرستاد مثل یکجور آلارم.
دم اذان صبح و ساعت 12 شب بیشتر از هزار پیام باید فرستاده میشد. یعنی ما در طول روز به طور معمول دو الی سه ختمهر ختم 604 صفحه ) اشتیم و تو این دو تا زمان به اندازه ترافیکی که تو کل روز پخش میشد ترافیک وجود داشت.
این رو بذارید کنار اون محدودیتی که تلگرام برا ربات ها گذاشته!
هر ثانیه فقط 30 کاربر پیامتو میگیرن !!
و یک مشکل بزرگتر! هیچوقت براش یک پنل طراحی نکرده بودیم. تا حداقل مشکلات ساده تر از طریق پنل حل بشه .
مشکل بعدی این بود که به دلیل های متعدد ارتباط با کاربر ها عملا ممکن نبود و نمیتونستیم یک پیام به همه بفرستیم .
اینطور شد که تصمیم گرفتیم مهاجرت کنیم و قصه این مهاجرت رو براتون تعریف میکنم .
امروز میخوام یکی از عادات عجیب خودم رو براتون بگم، شاید رسالت این بلاگ نوشتن عادات عجیب غریب من نباشه و امیدوارم مورد جاج قرار نگیرم؛ اما یکی از عادات عجیب من در مواقعی که روی پروژه های شخصی خودم کار میکنم استفاده از شخصیت های فانتزیه! شخصیت های فانتزی مورد علاقه‌م رو در پروژه دخیل میکنم.
یکی از سایت هام که البته خیلی وقته نابودشده اسمش تلگرال بود، توی اون سایت کاربرا ادرس کانال های تلگرامشونو وارد میکردن و به نوعی دایرکتوری کانالهای تلگرام بود. البته که اون سایت پیشرفت خوبی داشت و به جز چند مشکل سئو میتونست آینده درخشانی داشته باشه اما نکته بحثم جای دیگه‌س.
اون موقع تازه سریال بریکینگ بد رو تموم کرده بودم و محو شخصیت درجه سوم چهار ویکتور بودم. همه لاگهای سایت از جمله عضویت کاربرا، ثبت کانال جدید و . توی یک کانال شخصی برای خودم فوروارد میشد؛ اما اسم کامال رو "لاگهای سایت تلگرال" یا "telegral logs" نذاشتم! به طرز خنده داری اسم اون کانال شد Victor! برام اینطور بود که ویکتور بیست و چهار ساعته سایت رو میپاد و همه گزارش ها رو برام میفرسته.
قضیه به اینجا ختم نشد بعدا یک ربات جذب ممبر زدم و «ser barristan» از سریال گیم آف ترونز وظیفه گزارش جذب و دفع ممبرها رو داشت :))
بعد هم یک ربات ساختم که توی انتخاب واحد کمک حال دانشجوها بود؛ اینجا «john luck» از سریال دوست داشتنی لاست وظیفه گزارش ها رو داشت. اون بهم میگفت دانشجوها از چه درسهایی بیشتر خوششون میاد یا به چه درسایی کمتر علاقه دارن یا حتی برای این ترم میخوان کدوم درس ها رو بردارن:))
خلاصه اینکار به من کمک میکرد تا هم لاگهای مناسبی داشته باشم از سیستمم هم این لاگها توسط یک شخصیت فانتزی مورد علاقه‌م به من برسه. نمیدونم شاید اینجوری اون لاگ ها رو مهمتر میدیدم. حالا اگه با من کاری ندارید برم تا یکی دیگه از لاگرهام رو به یک شخصیت فانتزی بدل کنم ؛)
درباره این سایت