برای درک مفهوم Duck Test و کلا Duck Typing میتونیم با این مثال درمورد Promise ها نکاتی یاد بگیریم. فرض کنید فانکشنی داریم که یک Promise رو میگیره و حالا یک کاری انجام میده.

function doWork(promise) {
  promise.then(() => {
    console.log("Work Is Done");
  });
}

const newPromise = Promise.resolve("Hello Promise");
doWork(newPromise);

مثال خیلی ساده هست. به این نکته توجه کنید که ما اینجا هیچ نوع type check نداریم. و برنامه میتونه در runtime به مشکل بخوره اگر workPromise یک instance از Promise نباشد. توجه کنید ما همین الان هم داریم از Duck Typing استفاده میکنیم چون در doWork هیچ خبری نداریم و فقط then رو call میکنیم با فرض این که Promise یا Duck باشد.
حالا کد رو یکم بهتر میکنیم.

import { types } from "node:util";

function doWork(promise) {
  if (types.isPromise(promise)) {
    promise.then(() => {
      console.log("Work Is Done");
    });
  }
}

در "node:util" یک namespace داریم به اسم type که در اینجا یک سری فانکشن کمکی برای چک کردن تایپ ها ( Type predict function ) داریم که به ما کمک میکنن که کد safe تر باشه. الان این کد رو اگر اجرا کنید همه چیز اوکی هست و کار میکنه. ولی یک edge case اینجا وجود داره که خیلی کمتر به چشم میاد. با مثال بعد متوجه میشید ولی بزارید اول با یک سوال مطرح کنم موضوع رو.
اگر Promise Object ما از Native Promise خود #Javanoscript نباشد چه اتفاقی پیش میاد؟ قطعا این کد به مشکل میخوره چون isPromise فقط Native Promise ها رو چک میکنه و نه 3rd party ها که ممکنه در خیلی از code base ها باشه.
به عنوان مثال اگر از پکیج زیر استفاده شده باشه.
https://www.npmjs.com/package/promise
حالا اگر فقط این پکیج import شده باشه این کد به مشکل میخوره

import Promise from "promise";

حالا شما میگی ایمان خب با شرط رو با instaceof چک میکنیم که اگر این پکیج بود درست اجرا بشه. و شرط رو به این شکل عوض میکنید.

import Promise from "promise";
import { types } from "node:util";

function doWork(promise) {
  if (types.isPromise(promise) || promise instanceof Promise) {
    promise.then(() => {
      console.log("Work Is Done");
    });
  }
}

دوباره اینجا یک مشکل پیش میاد چون فقط همین یک پکیج نیست. به عنوان مثال اگر bluebird استفاده کرده باشن کد مشکل میخوره. خب منظورم رو تا الان متوجه شدین بریم سراغ Duck Test. اون جمله معروف که در پست اول گفتیم رو به یاد بیارید اول و حالا دقت کنید.
درسته این پکیج ها متفاوت هستند ولی همشون interface های یکسانی دارند. اینجا دوست دارم یک رفرنس بزنم به یک جمله معروف که اگر عمیق درکش کنید چند level یک شبه در برنامه نویسی پیشرفت میکنید.
"program to interfaces, not implementations"
اینجا دقیقا این lib ها از این مفهوم استفاده کردند برای Promise به ما implementation های زیادی داریم ولی نقطه مشترک همشون داشتن interface یکسان هست که به عنوان مثال همشون متد .then دارند. اصن وقتی در مثال بالا ما بدون تغییر کد فقط با import کردن کل ساختار رو عوض کردیم که کد به مشکل خورد مثال همین موضوع هست.
حالا کافیه با استناد به این جمله کلیدی و زیبا و Duck Test و فرض گرفتن که همه این lib ها متد .then رو دارند شرط رو عوض کنیم.

function doWork(promise) {
  if (promise && promise.then && typeof promise.then === "function") {
    promise.then(() => {
      console.log("Work Is Done");
    });
  }
}

حالا شما اگر شرط بالا رو به این صورت بنویسید (دقیقا مثل type predict ها در #TypeScript) میبینید که کد با هر library کار میکنه. چون شما وابستگی خودتون رو از implementation شکوندین و به interface وابسته شدین. مهم نیست که object ورودی یک instance از Promise خاصی باشد. مهم این هست که شبیه به Promise ها رفتار کند ( به عنوان مثال متد .then داشته باشد).

این بود مفهوم Duck Test به صورت کاربردی. توجه کنید که کد بالا به صورت production ready نیست و صرفا فقط برای توضیح مفاهیم بود.
امیدوارم خوشتون اومده باشه.

#Tip
#NodeJS

اگر تمام این مفاهیم که تا الان باهم یاد گرفتیم رو بخواهیم بندازیم دور و فقط و فقط یکیش رو یاد بگیریم. همین جمله معروف
"program to interfaces, not implementations"
میتونید درموردش داخل این stack overflow بیشتر یاد بگیرید.

https://stackoverflow.com/questions/2697783/what-does-program-to-interfaces-not-implementations-mean

تجربه شخصی : زندگی من بعد از درک این جمله قشنگ دو تیکه شد. قبل از یاد گرفتن این و بعد از یاد گرفتنش. یادمه از شدت خوشحالی که چقدر این موضوع قوی و باحاله اشک تو چشام جمع شده بود. و آرزو میکردم ای کاش خیلی قبل تر یکی این موضوع رو بهم میگفت.

من یک تشکر از دوستان کنم.
گروه چنل 100 نفره شد🎉.
از همه ممنونم امیدوارم گروه و چنل براتون مفید باشه❤️

یکی از مشکلاتی که در #NodeJS وجود داره Manage کردن ورژن های مختلف Package manager ها هست. همونطور که میدونید پکیج منیجر های مختلفی برای #NodeJS وجود داره که در پایین میبینید.
npm - bun - yarn - pnpm
حالا باتوجه به سلیقه شخصی هرشخصی در پروژه های خودشون از این پکیج منیجر ها استفاده میکنند. جدا از این ممکنه یک پروژه ای از یک ویژگی مربوط به یکی از اینها استفاده کنه که وابستگی زیادی بین پروژه و پکیج منیجر ایجاد میکنه.
فرض کنید یک پروژه رو میخواید به سیستم دوستتون انتقال بدید که از pnpm استفاده میکنه دوستتون yarn داره اینجا دوتا چالش به وجود میاد.
- چالش نصب pnpm به صورت دستی
- نصب ورژن مورد نیاز پروژه
حالا در همچین سناریو هایی #NodeJS در ورژن های v16.9.0, v14.19.0 ابزاری به اسم corepack اضافه کرده که بهتون کمک میکنه اعضای تیم خودتون رو سریعتر به مرحله productive بودن روی پروژه های جدید برسونید. وقتی nodejs رو نصب میکنید corepack به صورت پیش فرض نصب هست ولی به دلیل experimental بودن غیرفعال هست. برای فعال کردنش میتونید از command زیر استفاده کنید

corepack enable

بعد حالا اگر میخواید مثلا مشخص کنید که پروژه شما از pnpm نسخه 8 استفاده میکنه که در هنگام انقال همه چی فیکس باشه میتونید از این command استفاده کنید.

corepack use pnpm@8.x

بعد از این کامند به package.json شما یک attr اضافه میشه شبیه به زیر که ورژن دقیق package manager شما رو مشخص میکنه.

{
"packageManager": "pnpm@8.15.1+sha256.245fe901f8e7fa8782d7f17d32b6a83995e2ae03984cb5b62b8949bfdc27c7b5"
}

حالا اگر روی یک سیستم دیگ شما برای نصب package manager برای این پروژه از command زیر استفاده کنید تمام مشکلات بالا حل میشه و دقیقا package manager مناسب پروژه خواهید داشت

corepack install

این ابزار میتونه برای تیم هایی که با #NodeJS کار میکنند کمک خوبی باشه که دست خط های خودشون رو یکی کنند.

نظر شخصی : به تازگی روی یکی از پروژه ها محل کارم از این موضوع استفاده کردیم و در نگاه اول بازخورد خوبی داشتیم.

#Tip

مدتی هست در خبرنامه های #NodeWeekly خبر خاصی به چشمم نمیاد واقعا.
این هفته خبر اومدن نسخه 5.4 Typenoscript به صورت Beta رو دیدم.
https://devblogs.microsoft.com/typenoscript/announcing-typenoscript-5-4-beta/

و نسخه 6 برای فریم ورک AdonisJS که حرکت بزرگی زدن و به صورت پیش فرض اومدن روی ESM
https://adonisjs.com/blog/adonisjs-v6-announcement

سلام دوستان ارادت. همونطور که اطلاع دارید یک گروه داریم به اسم @NodeMasterGP که دور هم جمع شدیم تا بتونیم باهم پیشرفت کنیم.
اعضای گروه چند شب پیش داشتن درمورد موضوعی صحبت میکردن که در نهایت یکی از دوستان تصمیم گرفت یک وبینار رایگان برگزار کنه برامون.
مدرس این وبینار آقای رستم دخت سابقه خیلی زیادی در زمینه BackEnd دارن.
تاریخ برگزاری وبینار از ساعت 19:30 تا 22:30 روز چهار شنبه 18 بهمن ماه هست که میتونید شرکت کنید.

از این لینک میتونید ثبت نام کنید.
https://formafzar.com/form/f21m6

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

منبع :
https://blog.sonatype.com/npm-flooded-with-748-packages-that-store-movies

#Security

همیشه دنبال یک معادل مناسب برای #Python Beautiful Soup در اکوسیستم #NodeJS بودم که نخوام با headless browser ها scrap انجام بدم. امروز این پکیج رو پیدا کردم شما هم اگر دوست داشتید یک چک کنید.
https://www.npmjs.com/package/cheerio

بچه های #FrontEnd و #BackEnd هفته پیش Deno نسخه 1.40 منتشر شد توجه کنید. حالا سوال پیش براتون میاد که چه ربطی به ما داره. دو proposal مربوط به #EcmaScript در این آپدیت نکاتی وجود داره.
همونطور که میدونید Date در #Javanoscript همیشه مشکلات داشته و اکثرا از lib هایی مثل moment و ... استفاده میشد. استاندارد TC39 Temporal وارد Stage 3 شده و Deno ظاهرا اولین Runtime میباشد که این استاندارد رو پیاده سازی کرده و الان میتونید با فلگ unstable ازش استفاده کنید. قطعا به زودی شاهد پیاده سازی ها روی سایر Runtime ها مثل #NodeJS و مرورگر ها برای فرانت خواهیم بود.
لینک مربوطه :‌ https://tc39.es/proposal-temporal/docs/index.html
دقت کنید بهش میبینید ساپورت تقویم فارسی هم داره :)

const now = Temporal.Now.plainDateISO(); // Output => 2024-02-03

const twoDay = Temporal.Duration.from("P2D"); // Output => 2024-02-05

const twoDayLater = now.add(twoDay);
twoDayLater.toLocaleString("fa-Fa"); // Output => ۱۱۴۰۲/۱۱/۱۶

// Support for persian calender
twoDayLater.withCalendar("persian")

حالا این رو اینطور ران کنید.

deno run --unstable-temporal main.ts

موضوع بعدی مربوط به استاندارد TC39 Decorators هست. باتوجه به محبوب بودن Decorator ها در transpiler ها بعد از سالها بلاخره این هم وارد Stage 3 شد. یعنی به زودی شاهد Decorator ها در #JavaScript به صورت Native خواهیم بود. این ویژگی الان سمت Deno در آپدیت 1.40 اضافه شاده و به زودی شاهد اومدنش در مرورگر ها هم خواهیم بود. البته فایل ها #JavaScript محدودیت داره بخاطر پیاده سازی سمت انجین V8
لینک مربوطه : https://github.com/tc39/proposal-decorators

چند وقت پیش درمورد اضافه شدن impoer.meta.dirname و import.meta.filename در #NodeJS صحبت کردیم. در آپدیت 1.40 این ويژگی به Deno هم اضافه شد تا سازگاری با استانداردها و Runtime های دیگه حفظ بشه.
لینک پست : https://news.1rj.ru/str/NodeMaster/123
بلاگ پست مربوطه به این آپدیت دینو : https://deno.com/blog/v1.40

یکی از Flag هایی که به #NodeJS مدتی هست اضافه شده یعنی ورژن v20.6.0 که خیلی هم کاربردی هست مربوط به .env ها هست.
شما با فلگ زیر میتونید بدون استفاده از پکیج هایی مثل dotenv فایل های .env رو به راحتی لود کنید داخل پروژه خودتون.

node --env-file=.env --env-file=.development.env index.js

این ویژگی یکی از ویژگی های خوب Deno هست که به صورت builtin قرار داشت و تیم #NodeJS هم با تصمیم خوبی گرفتند که این رو اضاف کردند.
#Tip

سلام و خسته نباشید.
یک تیم ایرانی در حال توسعه یک فریم ورک با #Deno هستند و من با سازنده این فریمورک صحبتی داشتم.
لینک گیتهاب :‌https://github.com/MiaadTeam/lesan#many-thanks-to-those-who-supported-us

نقل از سازنده :
یک وب‌سرور بعلاوه ODM بر روی MongoDB، که با الهام از GraphQL مدیریت دریافت داده‌ها رو به سمت Client سپرده ولی خیلی از مشکلات اون رو نداره.
و از همه مهمتر یه تعریف جدید از رابطه‌ی بین داده‌ها ارائه می‌ده، که باعث میشه دریافت داده‌ها بسیار سریعتر انجام بشه و مدیریت اونها قابل فهم‌تر باشه. این فریم‌ورک تمام رابطه‌ها رو بدون دردسر امبد میکنه و سرعت خواندن اطلاعات توش وحشتناک بالاست.
(بنچمارک رو ببینید https://miaadteam.github.io/lesan/#benchmarks).
نوع نگاه لسان به رابطه‌ها باعث شده داده‌ها و کوئری‌ها برای دریافت اونها ساده سازی بشند، به همین خاطر کل فرآیند از کدنویسی تا لایه کش حتی دیتا ماین هم ساده میشه.

من خودم فرصت نکردم دقیق چک کنم ولی اگر دوست داشتید یک سر بزنید بهش نظراتتون رو بگید.

داکیومنت :
https://miaadteam.github.io/lesan/

ارتباط با تیم : @syd_amir

مدتی هست در گروره کانال @NodeMasterGP بچها خیلی درمورد ماهیت Async بودن و Single Thread بودن #NodeJS صحبت میکنند. یکی از env های استاندارد UV_THREADPOOL_SIZE هست. همونطور که میدونید پشت انجین #NodeJs یک کتاب خانه Native برای هندل کردن کار ها به صورت async میباشد. این native lib وظیفه دارد تا یک interface یکسان برای تمامی سیستم عامل ها به وجود آورد. بعضی از api ها به صورت کلی به صورت Sync هستن ولی معادل Async اون رو ما داخل NodeJS میبینیم. به عنوان مثال "node:crypto" برای ما cps async api داره ولی ذات اونها sync هست. حالا سوال پیش میاد که چطور چیزی که sync هست رو async کنیم.
در اینجا libuv یک راه حل هوشمندانه داره. با استفاده از Thread Pool pattern در MultiThreading و ایجاد صف از کار هایی که باید همزمان انجام بشوند api های sync رو تبدیل به async میکنه. هرکدوم از این ترد ها یک کار رو برمیداره انجام میده و دوباره میره سراغ کار بعدی. حالا شما میتونید تعداد thread هایی که در این استخر وجود داره رو کنترل کنید.( خیلی شبیه به معماری master slave هست )

export UV_THREADPOOL_SIZE=8
node main.js

تعداد thread های در pool به صورت پیش فرض ۴ هست. معمولا طبق best practise هایی که من مطالعه داشتم به صورت کلی میگن به تعداد هسته های CPU خوبه. اما اگر بخوایم دقیق تر به این موضوع نگاه کنیم فاکتور های خیلی زیادتری داریم که من خودم هنوز دقیق نتونستم مطالعه کنم درموردشون. سخت ترین کار پیدا کردن همین بالانس هست که یک اصول داره.

با استفاده از این env میتونیم رفتار #NodeJS رو خیلی دقیق تر نگاه کنیم در سناریو های مختلف.
این موضوع رو در‌ آینده حتما در یک ویدیو دقیق تر نگاه میکنیم تا رفتار های جالب #NodeJS رو در سناریو های مختلف ببینیم.

دوستان honeypot.io که در زمینه کاریابی فعالیت میکنه یک مستند درمورد #NodeJS داره میسازه که میتونید تریلر این مستند رو اینجا ببینید.
https://youtu.be/SfWPqr04srM?si=siu0S0JNd4QZnSxD

هر روز یک چیزی هست که ما رو سوپرایز کنه. یک Full Stack Framework برای #NodeJS دیدم که خیلی جالب هست.
https://wasp-lang.dev/
ظاهرا شبیهه به Prisma ORM که زبان خودش رو داره شما کل app با کد های Custom خودتون رو در یک فایل .wasp مینویسید و اون app شما رو میسازه.

مرسی از همتون رفقا واقعا دمتون گرم 600 نفر شدیم.❤️ 🎉
خیلی خیلی خوشحالم که تونستیم باهم یک کامینیوتی کوچیک تشکیل بدیم و رشد کنیم امیدوارم موفق باشید همگی❤️👍

دوست دارم یکم درمورد Dependency injection صحبت کنم. یکی از پایه ای ترین Pattern ها که اوایل در زبان های Static Type خیلی محبوب شد ولی به زبان های Dynamic Type هم راه پیدا کرد. هر گوشه ای که در صنعت نگاه کنید این تکنیک رو میبینید که در حال استفاده است. از فریم ورک های محبوب مثل Spring boot در #Java و NestJS در #NodeJS و Angular در کد های #FrontEnd #JavaScript . حالا سوال پیش میاد چرا از این تکنیک استفاده میکنن؟
یک اتومبیل رو در نظر بگیرید از اجزای زیادی تشکیل شده است این اجزا به هم وابستگی های ( Dependency ) زیادی دارن اما نحوه قرار گرفتنشون در کنار هم خیلی جالبه. به این شکل که اگر قطعه ای خراب شد نیاز نیست کل ماشین رو بندازیم دور و به راحتی میتونیم قطعه مورد نظر رو جایگزین با قطعه جدید کنیم.

یک موضوع دیگ بنظرم یوتیوب برید ویدیو راجع به خط تولید ماشین ها نگاه کنید. میبینید که در استیج های مختلف با این که ماشین هنوز آماده نیست قطعات کوچک تر رو جدا تست میکنن ( Unit Test ) بعد ماشین یا که کامل شد کل ماشین رو یکجا تست میکنند ( End2End Test ). حالا این تکنیک اگر درست استفاده بشه فرایند تست نوشتن رو خیلی براتون راحت میکنه. دوستان تست نوشتن برای برنامه ای که مینویسید از خود برنامه سخت تره. یکی از محدود خط کش هایی که میتونیم باهاش معیار کد خوب و بد رو مشخص کنیم کدی هست که بشه براش تست نوشت و کدی که بشه low mock test انجام داد.

معمولا همه جا راجع به کد #SOLID صحبت میکنن اما این رو هیچ وقت نمیگن که اگر به دنبال #SOLID شدن حرکت میکنید بدون Dep Injection تقریبا غیرممکن هست. نکته جالب این که خیلی از تازه کار ها در مفاهیم Object Orinted مشکل دارند به طوری که درک مفهومی مثل Abstraction برای تازه کار ها یکم سخت هست. اما اگر به این Pattern در آموزش ها دقیق تر پرداخته میشد. بعد از یک مدت کار کردن به این موضوع میرسید که ۴ اصل Object Orinted خیلی به صورت طبیعی براتون منطقی میشه. مخصوصا تکنیک Abstraction که ابزار ما مثل آچار برای مکانیک ها هست که بهشون کمک میکنه قطعات یک اتومبیل رو عوض کنن ( ما هم با Abstraction میتونیم برنامه خودمون رو تبدیل به قطعه های کوچک تر کنیم و این قطعات رو در صورت نیاز تعویض کنیم )

صحبت کردن در مورد این مفاهیم یکم پیچیده هست به دلیل این که خیلی با مفاهیم دیگ مرتبط هستن. چند وقت پیش یک پست گذاشتم که گفتم اگر میخواید فقط یک چیز از این چنل یاد بگیرید این رو یاد بگیرید. اون پست اینجا خیلی مرتبط هست ولی خب به دلیل طولانی شدن کاری بهش نداریم فقط اشاره کردم خودتون به عنوان تمرین یکم فکر کنید روش.
https://news.1rj.ru/str/NodeMaster/137

از اونجایی که دوست دارم به جای ماهی دادن، ماهیگیری یاد بدم از اینجا به بعد درمورد این که چطور یک مفهومی که هیچی ازش نمیدونیم رو باهم یادبگیریم.
در کتاب های الگوریتم یکی از اولین الگوریتم هایی که درموردش صحبت میکنن Divide and conquer ( معادل فارسی تفرقه بینداز و حکومت کن ) هست. این الگوریتم محدود به کامپیوتر فقط نیست و میتونید در یادگیری خیلی استفاده کنید. و یک نمونه رو اینجا باهم میبینیم. این الگوریتم اینطور هست که اگر مسئله ای داریم بیایم و اون رو مسئله های کوچک تر تبدیل کنیم و حال کنیم.
خب به این شکل هست که برای درک بهتره Dependency injection بهتره ما اول یاد بگیرم خود Dependency چی هست. بعد injection رو یاد بگیریم. بعد فکر کنیم که ترکیب این دوتا چطور میشه Dependency injection حالا به جای یک مسئله بزرگ ۳ مسئله کوچک تر داریم با ترتیب میتونیم حل کنیم. خب تبریک میگم الگوریتم Divide and conquer هم یاد گرفتید.

بریم برای سوال اول. Dependency چیست ؟

function syncLogic1() {}
function syncLogic2() {}

function job() {
  syncLogic1(); // dependency
  // Some codes
  syncLogic2(); // dependency
}
function main() {
  job(); // dependency
}

main();

ما دوتا لاجیک داریم که باید به ترتیب انجام شوند به عنوان مثال و فانکشن job کاری هست که باید انجام بشه. وقتی ما از یک function یا class به صورت مستقیم در یک function یا class دیگ استفاده میکنیم در حقیقت داریم وابستگی ( Dependency ) شدیدی ایجاد میکنیم. الان فانکشن main به job وابستگی داره و job به syncLogic1 و syncLogic2. اگر بخوایم یک مثال قابل لمس تر بزنیم

import { randomInt } from "node:crypto";

class SendOTP {
  sendSms() {
    const number = randomInt(1000, 9999); // dependency
    // Api call to send sms
  }
}

کد بالا فرض کنید میخوایم کد otp ارسال کنیم با استفاده از randomInt یک کد میسازیم و چون مستقیم از این فانکشن استفاده کردیم در SendOTP class وابستگی ایجاد کردیم.

به دلیل طولانی شدن ادامه بحث رو در پست های بعد عمیق صحبت میکنیم.

#Tip پارت اول.

اگر به وب سایت #TypeORM یک سر بزنید همون صفحه اول این مثال رو میبینید. اینجا یک pattern خیلی کاربردی داریم که خیلی کمتر بهش توجه میشه.

const user = new User()
user.firstName = "Timber"
user.lastName = "Saw"
user.age = 25

این چه پترنی هست؟ کامنت کنید صحبت کنیم
#Tip

دوستان. این آگهی استخدام از بچهای گروه خودمون هستن. چک کنید حتما
#Work

https://jobinja.ir/companies/barsaweb/jobs/ARrH/%D8%A7%D8%B3%D8%AA%D8%AE%D8%AF%D8%A7%D9%85-javanoscript-mid-level-back-end-developer-%D8%AF%D8%B1-%D8%A8%D8%B1%D8%B3%D8%A7%D9%88%D8%A8

یکی از مشکلاتی که میتونه داخل تیم ها بین #FrontEnd و #BackEnd باشه داشتن Api Doc مناسب هست. اکثرا همه از #Postman استفاده میکنن ولی به دلیل مشکلاتی که داخل ایران داریم و نمیتونیم از ویژگی های پولی این app در تیم ها استفاده کنیم. یکی از این ویژگی ها مهم ایجاد Workspace مشترک بین اعضای تیم هست. در تیم خودمون دنبال یک راه حل برای حل این مشکل بودیم که رسیدیم به #Hoppscotch. یک جایگزین مناسب برای #Postman که کاملا opensource هست و تمام ویژگی هایی که یک تیم توسعه نیاز داره به صورت رایگان در اختیار شما قرار میده. نکته خیلی خوب دیگ راجع به این ابزار توانایی self host کردن درون سازمانی هست که کامل وابستگی شما رو میتونه از عوامل بیرونی از بین ببره.

البته یک نکته مثبت دیگ این که نه تنها برای تمامی پلتفرم ها app native داره. بلکه نسخه وب هم داره که نیاز به نصب نداره.
اگر در تیمتون توانایی استفاده از ویژگی های پولی postman رو ندارید و دنبال راه حل مناسبی برای کمتر کردن رفت آمد بین تیمی برای گرفتن collection های بروز از api doc ها هستید قطعا یک نگاهی به این بندازید.

https://hoppscotch.io/

در پست قبل درمورد Dependency صحبت کردیم و یاد گرفتیم که Dependency چیست؟ سوال دومی که قرار بود درموردش صحبت کنیم این بود که Injection چیست؟ به مثال پایین دقت کنید.

import { randomInt } from "crypto";

// Normal Version
function generateOtp() {
  const otp = randomInt(1000, 9999); // dependency
  return otp;
}

// Injected Version
function generateOtp(fn) {
  const otp = fn(1000, 9000);
  return otp
}
const result = generateOtp(randomInt);

در ماشین ها یک قطعه داریم به اسم injector ( فارسی میگن انژکتور در حقیقت اینجکتور هست ). خب انجین نیاز به سوخت داره و این وسیله وظیفه inject کردن سوخت به انجین داره یعنی از این زاویه نگاه کنیم که انجین به سوخت وابستگی (Dependency) دارد و injector سوخت رو inject میکنه به انجین و حالا رسیدیم به خود Dependency Injection. میشه گفت این قطعه فریمورکی هست که کار Dependency Injection رو انجام میده برامون مثل #NestJS در #NodeJS و #Spring در #Java.
اینجا یک لاجیک ساده داریم که کد otp میسازیم. در نسخه اول خیلی ساده میایم فانکشن randomInt رو به عنوان Dependency در فانکشن generateOtp استفاده میکنیم. اما در نسخه دوم بجای این که مستقیم از randomInt استفاده کنیم اون رو از طریق argument به generateOtp پاس میدیم و از طریق reference که بهش داریم کد Otp رو generate میکنیم. در حقیقت ما فانکشن randomInt رو در فانکشن generateOtp با این کار که از طریق argument بهش inject ( تزریق ) کردیم.

پس اگر بخوایم جمع بندی کنیم که Injection چیست. یعنی یک object رو از طریق های مختلفی مثل argument ها در function پاس بدیم و مستقیم استفاده نکنیم.
حالا اگر تعریف بالا رو کامل تر کنیم به Dependency Injection میرسیم. به این صورت که بجای استفاده از مستقیم از Dependency اون رو به روش های مختلف مثل مثال دوم داخل object مورد نظر inject کنیم. یعنی در حقیقت generateOTP به randomInt وابستگی دارد و وقتی ما از طریق argument به randomInt رو inject میکنیم به generateOtp به این کار میگیم Dependency Injection.

حالا در برنامه نویسی OOP وقتی از class ها استفاده میکنیم. نکات دیگه ای هم هست که باید بهشون توجه کنیم
- singleton design pattern خیلی استفاده میشه و شما اگر از هر DI framework استفاده کنید روشی برای کنترل این موضوع به شما میده.
- فرایند Injection از طریق Constructor
- فرایند Injection از طریق setter method

اگر یکم بخوایم دقیق تر به DI نگاه کنیم در حقیقت DI یک نوع خیلی سفارشی سازی شده از IOC Pattern هست ( Inversion Of Control ). اگر یکم بخواید خودتون مطالعه کنید این اصطلاح DI/IOC رو خیلی کنار هم میشنوید. مثال هایی از IOC رو میتونید در سرتاسر اکو سیستم برنامه نویسی ببینید.

به صورت کلی در این پست با مفهوم DI به صورت خیلی ساده آشنا شدیم. پست بعدی به DI در برنامه نویسی Object Orinted نگاه میکنیم و درمورد نکات بالا مفصل حرف میزنیم و صد البته با Poor man di آشنا میشیم تا di container رو بتونیم بهتر یاد بگیریم
درمورد IOC هم در آینده به صورت کامل جدا صحبت میکنیم چون خیلی مهم هست و نباید به سادگی از کنارش عبور کنیم.

پارت دوم
#Tip