یکی از مواردی که می‌تونیم به عنوان معایب مایکروسرویس‌ها ذکر کنیم، بحث هزینه‌ست.
وقتی معماری مایکروسرویس داریم، یعنی باید چیزهای زیادی رو run کنیم.
فرضاً هر کدوم از سرویس‌ها به صورت ایزوله‌شده می‌ره بالا؛ یه سری از ابزارها به جای یک‌بار نصب‌شدن، بارها نصب می‌شن و این یعنی منابع بیشتری مصرف می‌شه و فضای آزاد کمتری خواهیم داشت.

آقای Sam Newman به این نکته هم اشاره کرده که مجبور می‌شیم برای ابزارهای غیر رایگان، به جای هزینۀ یک لایسنس، هزینۀ چند لایسنس رو پرداخت کنیم چون انگار روی چند ماشین مستقل نصب شدند!

حالا به معماری monolithic فکر کنید و اینکه قراره یک کپه کد بزرگ رو یک‌جا دیپلوی کنیم...

وقتی از معماری مایکروسرویس استفاده می‌کنیم، سرویس‌های مختلفی داریم که با هم دیگه حرف می‌زنند و ممکنه که برای جواب‌دادن یک درخواست کاربر (مثلاً گرفتن توئیت‌های اخیر) از ده‌تا مایکروسرویس مختلف تقاضا کنیم که بهمون دیتای لازم رو ارائه کنند؛ دیتاها توی هر سرویس serialize شدند و بعد unserialize و اتفاقات از این دست.

همین باعث می‌شه که latency سیستم بالا بره و کاربر زمان بیشتری رو معطل ریسپانس بمونه.

اوایل کارتون، وقتی شروع می‌کنید، همه‌چیز سحرآمیز و خفن به نظر میاد. تکنولوژی‌های براق، هوش از سرتون می‌بَره و هِی ذوق می‌کنید. اما جذابیت تکنولوژی‌ها هم مثل هر جذابیت دیگه‌ای که توی دنیا هست، بعد از مدتی از بین می‌ره و دیگه خبری از حال عجیبی که داشتید نیست. وقتی با Laravel آشنا شدم، احساس می‌کردم یه تسلای مدل Y خریدم و حس خوبی داشتم ولی وقتی جلوتر رفتم، دیگه این حس رو از دست دادم. (الآن این حس رو با محبوبان جدیدم یعنی Nest.js و Docker و ElasticSearch و RabbitMQ دارم)

وقتی از این مرحله عبور می‌کنید، می‌فهمید که تکنولوژی نهایتاً یه ابزاره که باید در جای خودش به کار بره. اگه بشه یه تکنولوژی رو به چکش تشبیه کرد، همۀ مشکلات ما میخ نیستند که راه‌حلشون چکش باشه! بعدش به Clean Code اهمیت می‌دید، بعدش ممکنه توی شیءگرایی سُر بخورید، بعدش با Design Patternها آشنا بشید، بعدش برسید به مباحث معماری سیستم و الی آخر.

در نهایت می‌فهمیم که همۀ اینها قرار بوده به درد یه چیز بخوره: حل مشکلات بیزنس!
اینکه دامین رو خوب بشناسیم و قوانین و محدودیت‌ها رو توی سیستم پیاده کنیم که مشتری خوشحال باشه و درآمد بیزنس بالا بره! اگه بشه این هدف رو به دست آورد، دیگه اهمیتی نداره که از فلان تکنولوژی خفن استفاده کردید یا با PHP7 پیش رفتید!

- I smell a rat!
- Yeah! It should be too problematic and weird...
- No, I mean it! I can smell a dead rat that is died under your bed!
- What? Wait! God! No! Here's a dead rat! What should I do with this?
- Why don't you dance with HER?
- Because I know you want to make a steak out of HER!
- I give up! You're so mean!
#english

راجع به پروژه‌ای که قرار بود معماری مایکروسرویس داشته باشه صحبت کرده بودیم و بعضی‌هاتون شوق نشون دادید؛ یه سیستم شبیه Google Calendar که بتونه جلسه‌ها و کارهای مهممون رو بهمون یادآوری کنه.

ریپازیتوری رو اینجا ساختم:
https://github.com/WebPajooh/calendar-microservice

کار خودم رو هم با سرویسی که مربوط به جمع‌آوری روزهای تعطیله شروع می‌کنم؛ از Typenoscript برای این سرویس استفاده می‌کنیم و فعلاً روزهای تعطیل ایران رو تشخیص می‌دیم. راه ارتباط سرویس‌های دیگه با این سرویس، REST API خواهد بود.

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

توضیح مفید و مختصر cohesion

Cohesion vs Coupling: Cohesion applies to the relationship between things inside a boundary (a microservice in our context), whereas coupling describes the relationship between things across a boundary.
#BuildingMicroservices

داشتم صحبت می‌کردم و دیدم سرعت خیلی خرابه، گفتم ای بابا اهل خونه دارن با نت چیکار می‌کنن! وای‌فای رو خاموش کردم...
بعد یادم افتاد که عجبا خودم هم به وای‌فای وصل بودم! 🤣

نتیجۀ اخلاقی: کسی که اینترنت رو قطع کنه، خودش قبل از همه ضرر می‌کنه.

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

حالا برعکس اون، بعضی از دولوپرها (به احتمال قوی با اجازۀ شرکت‌هاشون 😁) کار بامزه‌ای انجام دادند؛ یک فایل humans.txt درست کردند تا خودشون رو معرفی کنند! البته گاهی خبری از اسم دولوپرها نیست، ولی میدون حسابی برای شوخی باز شده!

چندتا نمونه رو ببینیم:
https://www.php.net/humans.txt
https://app.slack.com/humans.txt
https://medium.com/humans.txt

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

درس اخلاقی امروز: وقتی با اعداد و خصوصاً تاریخ سر و کار دارید، منطقی باشید!

خُب دِ نشد!
باز هم منطقی نبودیم! اصلاح‌شدۀ این کوئری هم تا نیم‌ساعت منفعل می‌مونه و این خیلی بده؛ این یعنی تا نیم‌ساعت فیچر مد نظر ما کار نمی‌کنه، و بعدش رفته رفته شروع به کار می‌کنه (اون هم ناقص) تا اینکه کامل بشه، و بعد یهو همه‌چیز ریستارت می‌شه!

منطقیش اینه که به جای چنین شرطی، پروداکت‌هارو به ترتیب تاریخ آپدیت مرتب کنیم و بعد ده‌تای اول (یعنی اون‌هایی که قدیمی‌تر هستند) رو آپدیت کنیم.

در ادامۀ باگ‌ها، بنگرید به اینجا که اگه null هم باشه، true می‌شه؛ چون:
typeof null === 'object' 😭

Time formatting in PHP

ببینید چی پیدا کردم!
labs.play-with-docker.com