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

اگر برای سرویستون تست مینویسید و تست های شما وابستگی به دیتابیس داره برای سرعت معمولا سعی میشه که تست ها با یک دیتابیس in-memory اجرا بشه که وابستگی بیرون نداشته باشه و دردسر کمتری هم این روش داره.
حالا مشکلی که اینجا وجود داشت این که اگر پروژه شما به #MongoDB وابستگی داشته باشه در این راه برای استفاده از پکیج مربوط به In memory در حالت هایی دردسر زیادی داره که استفاده از روش های پایین خیلی منطقی تره.

روش هایی که در این حالت میشد استفاده کرد به این صورت بودن:
- استفاده یک دیتابیس جدا و کاملا ایزوله
- استفاده از Service ها در CI/CD pipeline مثل github and gitlab services ( در صورت نبود دیتابیس in memory این روش خیلی بهتری هست )
https://docs.github.com/en/actions/use-cases-and-examples/using-containerized-services/about-service-containers
https://docs.gitlab.com/ee/ci/services/

برای دیتابیس های SQL هم معمولا از #Sqlite نسخه In-memory رو به عنوان engine در هنگام تست استفاده میکنن ولی به این نکته باید توجه داشت که #Sqlite مثل هر #SQL دیگ تفاوت هایی با بقیه دارد و اگر همون تست ها رو بخواید با دیتابیس دیگ مثل #Postgres و #MySQL اجرا کنید ممکنه به خطا بخورید که این هم بخاطر تفاوت ها هست. مخصوصا اگر در تست هاتون به Primary key وابستگی داشته باشید که قطعا خیلی زیاد پیش میاد. ولی درکل هندل کردنشون به طوری که روی همشون کار کنه کار سختی نیست و با ریفکتور کوچیک بیشتر مواقع این موضوع حل میشه.
نمونه کد برای اجرا کردن #Sqlite با #NodeJS پکیج استاندارد جدیدی که اخیرا اضافه شده.

import { DatabaseSync } from 'node:sqlite';
const database = new DatabaseSync(':memory:');

البته شما باید باتوجه به ORM که استفاده میکنید کانفیگ رو انجام بدید.

برای Redis هم که Package مربوط به redis in-memory هست میتونید نصب کنید و استفاده کنید.

و حالا میرسیم برای #MongoDB دردسر ساز که این پکیج کارتون رو راه میندازه. نکته ای که وجود داره این که شما اگر بخواید با استفاده از in memory mongo پروژه خودتون تست کنید اگر هر نسخه از #NodeJS کانتینر برای تست خودتون استفاده کنید کار نمیکنه که جزیاتش رو میتونید داخل داکیومنتش ببینید و البته در این حالت ترجیح میدم از سرویس services مربوط به gitlab یا github استفاده کنم.
https://github.com/typegoose/mongodb-memory-server

قبلا در مورد استفاده از jsonb در #postgres صحبت کردیم و به صورت خلاصه اشاره کردیم چرا میتونه خوب باشه. امروز دوباره قراره یک نکته دیگ که خیلی خیلی میتونه مفید باشه یاد بگیرم. این که چطور اطلاعات یک جدول رو تبدیل کنیم به json ؟
حالا سوالی که برامون پیش میاد اصلا چرا باید همچین کاری کنیم؟ به صورت کلی گاهی اوقات نیاز دارید در هنگام Query زدن اطلاعات مربوط به polymorphic table ها رو همه و همه با جزیات در یک Query ببینید. در #MySQL ظاهرا راه حل های Native برای این گونه مسائل وجود داره که در آینده باهم یاد خواهیم گرفت ولی در Postgres با کمک Json ها که آزادی عمل زیادی بهتون میده میتونید هر کاری کنید از جمله حل کردن این گونه مسائل.

فرض کنید یک users table داریم با column های id, name , email. حالا میخواهیم تمام اطلاعات مربوط به هر row رو داخل یک column به اسم user_data داشته باشیم

SELECT to_json(users) AS user_data FROM users;

خب در اینجا ما از فانکشن کمکی to_json کمک گرفتیم که هر row در جدول users رو به json تبدیل کنیم که سطون های جدول users به عنوان key و مقادیر هر row به عنوان value در نظر گرفته میشود. این فانکشن کمکی به صورت کلی یکم محدود هست به این که کل سطون ها رو تبدیل به json میکنه. حالا اگر بخوایم قبل از json شدن روی دیتا مربوط به اون column های خاص یک کاری انجام بدیم مثلا type cast انجام بدیم چکار باید کنیم؟
اینجا json_build_object به نجات ما میاد.

SELECT
  json_build_object(
    'id',
    u.id :: TEXT,
    'base_mail_name',
    split_part(u.email, '@', 1),
    'fqdn',
    split_part(u.email, '@', 2)
  ) AS users_data
FROM
  users AS u;

اینجا رسما دیتا مربوط هر row رو میگیرم و دستی به شکلی که میخوایم در Result set نهایی داشته باشیم شکل میدیم. فانکشن json_build_object تعداد زوج از param ها رو میگیره که param های فرد به عنوان Key و param های زوج به عنوان Value نهایی ما در json هستن. فانکشن split_part هم مثل اینجا صرفا برای split کردن یک string هست مثل متد split در #JavaScript عمل میکنه.

به صورت کلی فانکشن های کمکی خیلی زیادی برای کار کردن با json ها در #Postgres هستن ولی این دوتا بین اون ها خیلی کاربردی تر هستن. بقیه خیلی خیلی خاص تر هستن. کلا استفاده از همین ها هم خیلی نمیبینیم چون به صورت روزمره کاربردی نیستن ولی داخل سناریو های خاصی که بالا به یکیش اشاره کردم این ها کمک خیلی بزرگی میکنند. یا حتی در استفاده از Union برای ایجاد یک interface یکسان برای Table های مربوط در Query.

نکته بعدی این که هردو فانکشن بالا ورژن jsonb هم دارند.

to_jsonb
jsonb_build_object

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