فرض کنید می‌خوایید یه سرویس کوچیک بالا ببرید که به یه سری سرویس دیگه سرویس بده. (چه سرویس تو سرویسی شد)

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

بسته به نیاز و ماهیت دیتای هر سرویس، ممکنه سراغ دیتابیسی relational مثل MySQL و برای یه سرویس دیگه سراغ دیتابیسی مثل MongoDB بریم. حالا سؤال بعدی اینه که این‌ها سنگین در نمیان؟ سرویسی که دیتای خیلی کمی داره و به غالب فیچرهای MySQL یا MongoDB نیاز نداره، چرا باید از این‌ها استفاده کنه؟ وقتی ترنزکشن نمی‌خوام و شاید flat-file کارم رو راه بندازه، چرا گربه رو با RPG بکشم؟

اگه دنبال یه دیتابیس relational یا همون رابطه‌ای باشیم، SQLite یه گزینۀ جالب و خیلی سبُکه که می‌شه بررسی کرد. حجم ایمیج فشرده‌شده‌اش توی داکرهاب، حدود هشت مگابایته! از اون طرف RethinkDB رو داریم که در مقایسه با MongoDB حجم کمتری داره.

یه سری لینک:
https://relevant.software/blog/microservices-database-management
https://rethinkdb.com/docs/quickstart
https://stackoverflow.com/questions/63385922/is-it-bad-to-use-json-files-instead-of-real-databases
https://stackoverflow.com/questions/13899342/can-we-use-json-as-a-database

چطور چیزی مثل pluck رو توی JS داشته باشیم؟
let array = items.map(item => item['fieldName'])

The problem with arrays is that their shape is undefined. Clients wouldn’t know how they can extract from it the information they need.

ادیت: این دو جملۀ نوباک رو با گوشت و خون حس کردم! وقتی شما از روی یه کلاس آبجکت بسازی، دقیقاً مشخصه که داخلش چه پراپرتی‌هایی داری، ولی ساختار آرایه مشخص نیست و هرچی فکرش رو کرده باشید یا نکرده باشید رو می‌شه داخلش گذاشت. البته توی Typenoscript می‌شه تایپ‌های محدودتری ساخت، ولی در نهایت آرایه ساختارش نامشخصه.
#MathiasNoback

طراحی‌های هزینه‌بر و غیر مؤثر از سه منبع ناشی می‌شوند:
■ یک راه حل پیچیده برای یک مشکل ساده
■ یک راه حل ساده ولی نادرست برای یک مشکل پیچیده
■ یک راه حل نامناسب و پیچیده برای یک مشکل پیچیده
#code_complete

در همین راستا:

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

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

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

راه‌حل اول، یه مثال خوب برای راه‌حل نامناسب و پیچیده‌ای بود که برای یه مشکل ساده در نظر گرفتیم!

آقای Michael Feathers می‌گه: از نظر من، Legacy Code یعنی کدی که تست نداشته باشه.

جناب Robert Martin از اون طرف می‌گه: می‌دونم مسخره به نظر میاد، ولی قابل ملاحظه‌ست که اگه کدهای پروداکشن شما یه جوری حذف بشه و فقط تست‌هاش بمونه، می‌تونید کل سیستم با کمی تلاش بازنویسی کنید!

بعد Noback توی کتاب Advanced Web Application Architecture که قبلاً معرفی کرده بودم، برعکسش رو می‌گه: اما اگه فقط کدهای پروداکشن رو داشته باشید، اینکه براش تست بنویسید خیلی سخته!

سیستم ما، در هر ساعت، 2566~ ریکوست به یه سرویس دیگه می‌زد که با همّت بنده به 1269~ ریکوست رسید و احتمالاً در نهایت به 670~ ریکوست برسه. 😎

It makes sense for PHP to have a weak type system. Being a language that mainly works with a HTTP request, everything is basically a string.
#BrentRoose

This pattern of wrapping unstructured data in types, so that we can use that data in a reliable way, is called “data transfer objects”. It's the first concrete pattern I highly recommend you to use in your larger-than-average Laravel projects.
#BrentRoose