JS Lover

what are all method for create a object in javascript

چطوری بفهمم یه کامپوننت داره بار زیادی به دوش میکشه؟ هر کامپوننت در React باید فقط یک دلیل برای تغییر داشته باشه. یعنی فقط یک کار رو انجام بده، و اون رو عالی انجام بده. وقتی یه کامپوننت هم داده می‌گیره، هم fetch می‌کنه، هم state می‌چرخونه، هم UI می‌سازه……

چرا وقتی میخواییم توی نکست از svg استفاده کنیم توی پروداکشن عکس لود نمیشه؟ دلیل فنی‌اش اینه که Next.js image optimization pipeline (سیستم بهینه‌سازی تصاویر) برای فرمت‌هایی مثل JPG یا PNG طراحی شده که نیاز به ریسایز یا فشرده‌سازی دارن. اما SVGها فایل‌های برداری هستن، یعنی resolution-independent (وابسته به رزولوشن نیستن) و اساساً نیازی به بهینه‌سازی ندارن. در محیط standalone build (یعنی وقتی از next build && next start استفاده می‌کنی و فایل‌ها از /public سرو می‌شن)، Image optimizer سعی می‌کنه درخواست SVG رو از مسیر _next/image?... بگیره، ولی اون مسیر دسترسی به /public نداره. نتیجه؟ خطای 400 Bad Request. پس راه درست و رسمی اینه که برای SVGها بنویسی: <Image src="/logo.svg" alt="logo" width={100} height={100} unoptimized /> یا حتی بهتر: برای SVGها به جای <Image> از <img> ساده استفاده کنی یا اون‌ها رو به‌صورت React component import کنی: import Logo from '@/public/logo.svg'; <Logo /> خلاصه‌ی منطقی: • ✅ SVG = نیازی به بهینه‌سازی نداره. • ⚙️ unoptimized = جلوگیری از خطای 400 و درخواست بی‌معنا. • 🔒 Standalone mode = دسترسی مستقیم به public assets نداره. پس بله، اضافه کردن unoptimized کاملاً بهترین تصمیمه و مطابق با توصیه رسمی Next.js.

چطوری بفهمم یه کامپوننت داره بار زیادی به دوش میکشه؟ هر کامپوننت در React باید فقط یک دلیل برای تغییر داشته باشه. یعنی فقط یک کار رو انجام بده، و اون رو عالی انجام بده. وقتی یه کامپوننت هم داده می‌گیره، هم fetch می‌کنه، هم state می‌چرخونه، هم UI می‌سازه… دیگه «کامپوننت» نیست — یه پروژه‌ی مستقل شده. اصل SRP (Single Responsibility Principle) از فلسفه‌ی Clean Code می‌گه: «هر ماژول باید تنها یک دلیل برای تغییر داشته باشد.» – Uncle Bob همین یک جمله، اگر درست فهمیده بشه، کل معماری پروژه‌ت رو نجات می‌ده. چون وقتی هر کامپوننت فقط مسئول خودش باشه، کدها قابل‌فهم‌تر می‌شن، با خیال راحت‌تر تغییر می‌کنی، و هیچ باگی از گوشه‌ی دیگه‌ی سیستم بهت زهر نمی‌زنه. کامپوننت باید مثل یه کارگر دقیق باشه، نه مثل یه مدیر خسته که همه کارها رو با هم می‌خواد انجام بده. #بخش_اول #Best_Practice #React @js_loverr

✨ اما Bulletproof React | معماری پیشنهادی برای اپلیکیشن‌های React 🔶 توضیحات: اما Bulletproof React یک ریپوی متن‌باز است که بهترین الگوها و ساختار پوشه‌ها را برای ساخت اپلیکیشن‌های React در مقیاس بزرگ پیشنهاد می‌دهد. 🔷 ویژگی‌ها: • معماری ماژولار و قابل نگهداری • الگوهای استاندارد برای پروژه‌های enterprise • مستندات و مثال‌های عملی 🔷 اطلاعات بیشتر: ریپوی GitHub #React #BulletproofReact #Frontend #OpenSource 🔷 @Recomendersystem2023

نسخه‌ی Next.js 15.3 که در آوریل ۲۰۲۵ منتشر شده، یک گام بزرگ به سمت بهینه‌سازی عملکرد، تجربه بهتر توسعه‌دهنده و آماده‌سازی زیرساخت‌ها برای آینده‌ی بدون Webpack است. در این نسخه، ابزار جدید Turbopack حالا برای ساخت نسخه‌ی production در دسترس قرار گرفته (هرچند فعلاً در حالت alpha). این یعنی توسعه‌دهندگان می‌توانند با اجرای `next build --turbopack`، اپلیکیشن خود را با سرعتی بسیار بالاتر از Webpack بسازند؛ طبق تست‌ها تا ۸۳٪ سرعت بیشتر در سیستم‌های چند هسته‌ای گزارش شده است. Turbopack همچنان در حال توسعه است و توصیه می‌شود فعلاً فقط در محیط‌های staging یا تست از آن استفاده شود، نه در productionهای حساس. در کنار آن، پشتیبانی آزمایشی از Rspack نیز معرفی شده؛ یک bundler جدید که مانند Webpack API دارد اما با سرعت بسیار بیشتر و به زبان Rust توسعه داده شده است. اگر پروژه‌ای دارید که هنوز به Webpack وابسته است، می‌توانید با استفاده از پکیج غیررسمی `next-rspack` از مزایای سرعت بیشتر بدون ترک کامل ساختار Webpack بهره‌مند شوید. در بخش client-side، قابلیتی جدید به نام Client Instrumentation Hook معرفی شده که به شما امکان می‌دهد پیش از رندر شدن اپ در مرورگر، کدی برای آنالیتیکس، ردیابی خطا یا ثبت داده اجرا کنید. این فایل به‌صورت instrumentation.client.js در پوشه‌ی روت پروژه قرار می‌گیرد و اجرای آن پیش از mounting انجام می‌شود؛ مشابه رفتار instrumentation.ts در سمت سرور. همچنین دو هوک جدید برای مدیریت ناوبری افزوده شده‌اند: onNavigate که به <Link> اجازه می‌دهد رفتار ناوبری را کنترل یا حتی متوقف کند (مثلاً قبل از ترک صفحه، چیزی تأیید شود)، و useLinkStatus که وضعیت ناوبری در حال انجام را نمایش می‌دهد (مثل حالت pending). این ابزارها برای بهبود تجربه کاربری و ساخت رابط‌های منعطف بسیار کاربردی هستند. در حوزه‌ی TypeScript، پلاگین اختصاصی Next.js به‌روزرسانی شده و حالا در پروژه‌های بزرگ با فایل‌های زیاد، تا ۶۰٪ سریع‌تر عمل می‌کند. این ارتقا باعث کاهش لگ‌های IntelliSense، نمایش بهتر خطاها و تجربه‌ی روان‌تر در IDEهایی مثل VSCode می‌شود. در نسخه‌ی 15.3 همچنین برخی بهبودهای کوچک و مهم اعمال شده‌اند؛ مثل پشتیبانی پیش‌فرض از ویژگی sizes="100vw" برای next/image در حالت fill، و پشتیبانی از فایل‌های .cts و .mts در middlewareها و instrumentation. این موارد برای توسعه‌دهندگانی که با TypeScript پیشرفته و معماری‌های ماژولار کار می‌کنند، بسیار مهم هستند. با این حال، یک تغییر کلیدی که باید به آن توجه کرد این است که متد generateMetadata دیگر در client component‌ها کار نمی‌کند و فقط باید در server componentها استفاده شود. اگر اپلیکیشن شما کاملاً client-side است، این تغییر ممکن است باعث شکست در meta tagها و SEO شود و نیاز به بازنگری ساختار صفحات داشته باشد. در مجموع، Next.js 15.3 نقطه‌ی عطفی در حرکت به سمت ابزارهای مدرن‌تر، سریع‌تر و قابل اطمینان‌تر است. Turbopack و Rspack در حال تبدیل شدن به آینده‌ی bundling در اکوسیستم React هستند، و ابزارهای جدید client-side نیز به توسعه‌دهندگان این امکان را می‌دهند که کنترل بیشتری روی تجربه کاربری داشته باشند. این نسخه برای پروژه‌هایی که به عملکرد، مقیاس‌پذیری و توسعه‌پذیری اهمیت می‌دهند، به‌روزرسانی بسیار ارزشمندی محسوب می‌شود. https://nextjs.org/blog/next-15-3

در نسخه‌ی جدید Node.js یعنی v24.3.0 که در تاریخ ۲۷ ژوئن ۲۰۲۴ منتشر شده، مجموعه‌ای از بهبودها، اصلاحات و قابلیت‌های جدید معرفی شده که بیشتر آن‌ها در راستای افزایش عملکرد، قابلیت اطمینان، و پشتیبانی بهتر از ابزارهای توسعه و ماژول‌های مدرن هستند. در این نسخه، یکی از مهم‌ترین تغییرات اضافه شدن رویداد جدیدی به ماژول HTTP است. حالا با استفاده از رویداد 'headers' می‌توان قبل از خواندن بدنه‌ی درخواست، به هدرها گوش داد و مثلاً درخواست‌های نامعتبر را زودتر قطع کرد؛ قابلیتی که برای بهینه‌سازی امنیت و مدیریت منابع بسیار مفید است و فعلاً به‌صورت آزمایشی ارائه شده. در بخش پشتیبانی از ماژول‌ها، قابلیت استفاده از فلگ --experimental-default-type از طریق API node:module نیز فراهم شده که به ابزارهای build مثل bundlerها یا تست فریم‌ورک‌ها اجازه می‌دهد راحت‌تر تعیین کنند که فایل‌ها به‌صورت پیش‌فرض به چه نوعی (CommonJS یا ESM) تفسیر شوند. همچنین باگی که در اجرای مجدد فایل‌های ESM هنگام استفاده از --watch وجود داشت رفع شده، و حالا توسعه‌دهندگان می‌توانند با اطمینان بیشتری در حالت ماژول‌محور، کدنویسی reactive انجام دهند. در ابزار تست داخلی node:test نیز بهبودهایی اضافه شده، از جمله اینکه حالا قابلیت‌های پاک‌سازی (cleanup) تست‌ها در زمان fail یا stop به‌درستی اجرا می‌شوند. این مسئله به توسعه‌دهندگان کمک می‌کند تست‌هایی قابل اعتمادتر و ساختارمندتر بنویسند. در سطح داخلی، به‌روزرسانی موتور V8 به نسخه‌ی ۱۲.۴ صورت گرفته که باعث بهبود سرعت اجرای جاوااسکریپت و مصرف بهینه‌تر حافظه شده. همچنین ICU نیز به نسخه‌ی ۷۴.۱ ارتقاء یافته که موجب ارتقاء پشتیبانی از زبان‌ها، تاریخ‌ها، و قالب‌بندی‌های بین‌المللی شده است. این یعنی عملکرد بهتر در اپلیکیشن‌هایی که کاربران بین‌المللی دارند یا نیازمند پشتیبانی از تقویم‌هایی مثل شمسی، میلادی، بودایی و... هستند. تغییرات کوچکی نیز در ماژول‌های داخلی مانند timers و process اعمال شده که باعث بهبود رفتار تابع‌هایی مثل setImmediate و process.nextTick در سناریوهای با بار بالا می‌شود. همچنین خروجی process.abort() اکنون اطلاعات دقیق‌تری از وضعیت حافظه هنگام توقف ناگهانی فرآیند ارائه می‌دهد، که در دیباگ کردن خطاهای سخت بسیار ارزشمند است. در نهایت، چندین باگ گزارش‌شده نیز در این نسخه رفع شده‌اند؛ از جمله مشکل حافظه در هنگام استفاده از CommonJS در حالت watch، اختلال در عملکرد AbortController در HTTP، و خطای مربوط به dynamic import. در مجموع، نسخه‌ی ۲۴.۳.۰ بیشتر روی بهبود تجربه توسعه‌دهندگان، پایداری در استفاده از ESM، و سازگاری بهتر با ابزارهای تست و build تمرکز دارد و برای پروژه‌هایی که نیاز به کارایی بالا، قابلیت ماژولار پیشرفته، و تست‌پذیری خوب دارند، نسخه‌ای به‌روز و مطمئن به‌شمار می‌رود. https://nodejs.org/en/blog/release/v24.3.0

نسخه‌ی ۲۴ از Node.js یکی از بزرگ‌ترین به‌روزرسانی‌های سال‌های اخیر محسوب می‌شه، به‌خصوص برای توسعه‌دهنده‌هایی که هم در فرانت‌اند و هم در بک‌اند فعال هستن. این نسخه با تمرکز بر سازگاری بیشتر با ویژگی‌های مدرن جاوااسکریپت، امنیت بهتر، عملکرد سریع‌تر و راحتی بیشتر در توسعه، قدم بزرگی به جلو برداشته. یکی از مهم‌ترین تغییرات، ارتقای موتور جاوااسکریپت V8 به نسخه‌ی ۱۳.۶ هست که باعث شده پشتیبانی از امکاناتی مثل Float16Array، ویژگی جدید using/await using برای مدیریت صریح منابع، تابع RegExp.escape، پشتیبانی از WebAssembly Memory64، و متد Error.isError() به Node اضافه بشه. این تغییرات هم سطح Node.js رو با مرورگرهای مدرن هماهنگ‌تر کرده، هم کد نویسی رو امن‌تر و قدرتمندتر. نسخه‌ی ۱۱ از npm هم همراه با Node 24 عرضه شده که نصب پکیج‌ها رو سریع‌تر، مطمئن‌تر و سازگارتر با اکوسیستم توسعه‌ی مدرن کرده. علاوه‌بر اون، AsyncLocalStorage با استفاده از پیاده‌سازی جدید AsyncContextFrame بهبود پیدا کرده که برای اپ‌هایی که heavily async هستن یا از ردیابی context استفاده می‌کنن مثل لاگ‌گیری و ترسیم مسیر اجرا، بسیار مفید خواهد بود. از نظر امنیتی، ویژگی جدید Permissions حالا به صورت رسمی و پایدار در دسترسه. یعنی حالا می‌تونی با فلگ‌هایی مثل --allow-fs-read یا --allow-env مشخص کنی اپلیکیشن فقط به منابع خاصی دسترسی داشته باشه — شبیه مدل امنیتی Deno. یکی دیگه از نکات جذاب این نسخه، اضافه شدن global بودن کلاس URLPattern هست. دیگه نیاز نیست ایمپورتش کنی، به‌صورت سراسری قابل استفاده‌ست و به راحتی می‌تونی URL ها رو پارس یا مچ کنی. در تست‌نویسی هم تغییر خوبی اتفاق افتاده. حالا در تست‌رانر داخلی Node نیازی به await در زیرتست‌ها نیست و خودش مدیریت async بودن اون‌ها رو به عهده می‌گیره، که نوشتن تست‌های تو در تو رو ساده‌تر کرده. همچنین، نسخه‌ی ۷ از کلاینت HTTP رسمی Node یعنی undici حالا به صورت پیش‌فرض اومده که نه تنها ~۳۰٪ سریع‌تره، بلکه پشتیبانی بهتری از HTTP/2، درخواست‌های موازی، و retry داره. این مورد برای اپ‌های real-time یا API محور خیلی مهمه. در نهایت، تعدادی از APIهای قدیمی که دیگه استفاده نمی‌شن یا ناامن هستن deprecated یا حذف شدن، مثل url.parse()، SlowBuffer و بعضی متدهای child_process و zlib. https://thenewstack.io/node-js-24-your-next-big-frontend-upgrade/

مکالمه کوتاه در مورد دپلوی آپ ریاکتی: اگه حوصله داری در مورد داکر بخون و کدت رو روی یه کانتینر nginx بزار و deploy کن اگه نه میتونی روی خود سرور nginx رو نصب کنی و کانفیگ اش کنی که فایلهای خروجی رو برات serve کنه توی کانفیگش باید همچین چیزی بزنی که اپ ات درست کار کنه اگه روتر اش روی history mode هست root /path/to/files/ try_files $uri /index.html البته یکم در مورد خود nginx بخون و این که ساختار کانفیگ اش چطوریه بعد همین دو خط کافیه برای این که بدونی یه پروژه cra رو چطوری serve کنی البته این ساده ترین حالتش هست که کار می کنه فقط کانفیگهای مربوط به کش و ... هم میشه اعمال کرد که خب ممکنه این کارها رو توی cdn کرده باشی در کل برای deploy یه همچین چیزی نیازی به سرور نیست میتونی روی آبجکت استوریج آروان بزاری (رایگان تا ۵ گیگ ) و توی cdn اش تنظیم کنی که سایتت روی اون دامنه ای که میخوای بالا بیاد کاملا رایگان و با ظرفیت نا محدود خیلی توضیحش طولانیه و روش های زیادی هم داره طبیعتا اگه با داکر کار کرده باشی میدونی چطوری یه کانتینر رو اجرا کنی روی سرور ولی بخوایم چند تا کلید بگم اینه: docker build docker push docker swarm portainer docker compose traefik جای خاصی که همه چیز رو یه جا داشته باشه من ندیدم (در واقع تا حالا نیازم نشده) ولی احتمالا توی آینده نزدیک یه roadmap بنویسم برای شروع شاید roadmap.sh برای devops خوب باشه این این کانال و گروه discussion اش هم هست که نسبتا فعاله: https://t.me/DevOpsHobbies https://t.me/joinchat/Vf4iQf8U-fkI4cYZ یه roadmap هم دارن که توی همون کانال هست

برای اجرای ابونتو روی سیستم عامل های دیگه مثل هلو: 1. نصب داکر: https://docs.docker.com/desktop/setup/install/windows-install/ 2. سری اول بعد تموم شدن نصب داکر دانلود کانتینر ابونتو هست :) docker pull ubuntu 3.بعد دانلود توی عکسی که میدم دکمه اجرا رو بزنی تا لینوکس اجرا شه 4.در در آخر دستور زیر رو میزنی تا ترمینال داکر اجرا شه: docker attach container-id شناسه کانتینتر هم توی عکس علامت زدم #لینوکس

ری‌اکت ۱۹ بالاخره اومد و من امروز فرصت کردم یه سری از تغییراتش رو ببینم و تست کنم. خلاصه چند تا از ویژگی‌های جدید و جالبش رو اینجا براتون می‌نویسم که قراره واقعاً نحوه کدنویسی‌مون رو تغییر بده: - هوک use: حالا می‌تونیم مستقیماً تو رندر با پرامیس‌ها کار کنیم! دیگه خبری از استفاده‌های پیچیده از useEffect و لودینگ‌های دستی نیست. هر جا پرامیس داشته باشیم، use میاد به کمکمون. - اکشن‌های سمت سرور: خیلی باحاله! دیگه نیازی نیست برای هر فرم یا دکمه، API جدا تعریف کنیم. مستقیماً تابع سمت سروری که می‌خوایم رو به عنوان اکشن به فرم میدیم و کار تمومه. - آپدیت خوشبینانه: با هوک useOptimistic می‌تونیم UI رو سریع آپدیت کنیم، حتی قبل از اینکه جواب سرور بیاد! یعنی کاربر معطل نمی‌مونه و همه چی روان‌تر پیش می‌ره. - کامپوننت‌های سمت سرور: حالا می‌تونیم بدون نگرانی از کامپوننت‌های سمت سرور استفاده کنیم که یعنی سرعت لود بیشتر و سئوی بهتر. - خداحافظی با PropTypes: تایپ‌اسکریپت رسماً شده راه‌حل اصلی تایپ‌چکینگ. اگه هنوز از PropTypes استفاده می‌کنید، وقتشه به hashtag#تایپ‌اسکریپت مهاجرت کنید! - مدیریت فرم‌ها: با هوک جدید useFormStatus، مدیریت وضعیت فرم‌ها خیلی ساده‌تر شده. وضعیت لودینگ، خطاها و موفقیت رو راحت می‌تونیم کنترل کنیم. - متادیتای صفحه: دیگه نیازی به کتابخونه‌های اضافی برای مدیریت متادیتا نیست. مستقیم توی کامپوننت می‌تونیم متاتگ‌ها رو تعریف کنیم و React اون‌ها رو مدیریت می‌کنه. - بهبود Suspense: لودینگ‌ها خیلی هوشمندتر شدن. React سریع‌تر فالبک رو نشون میده و همزمان بقیه قسمت‌ها رو هم رندر می‌کنه. - رف به عنوان پراپ: دیگه می‌تونیم مستقیماً از ref به عنوان پراپ استفاده کنیم و دیگه نیازی به forwardRef نداریم. کد تمیزتر و خوانایی بیشتر. - خداحافظی با API‌های قدیمی: خیلی از API‌های قدیمی مثل render و findDOMNode رفتن کنار. حالا همه چی مدرن‌تر و بهینه‌تر شده. نکته طلایی مهاجرت: قبل از پریدن به نسخه ۱۹، حتماً اول به ۱۸.۳.۱ مهاجرت کنید! این نسخه بهتون هشدار میده که کجاها ممکنه با نسخه ۱۹ به مشکل بخورید. در کل، به نظر میاد ری‌اکت ۱۹ قراره تجربه توسعه رو بهتر کنه، مخصوصاً با قابلیت‌های جدید سمت سرور و بهینه‌سازی‌های عملکردی که اضافه شده‌اند. @DevTwitter | <AmirMohammad Sakizadeh/>

معماری‌های نرم‌افزاری در حوزه برنامه‌نویسی بسیار متنوع هستند و هر کدام با تمرکز بر اهداف، نیازها و شرایط خاصی به‌کار می‌روند. در این پست، تعدادی از معماری‌های پرکاربرد را میگم و توضیح می‌دهم که روی چه حوزه‌ای متمرکزند، کجا استفاده از آن‌ها مناسب هست و کجا بهتر استفاده نشه. ————————————————— معماری لایه‌ای (Layered Architecture) تمرکز:تفکیک مسئولیت‌ها بر اساس لایه‌های منطقی (Presentation، Business، Data Access). استفاده ش: سیستم‌های کلاسیک سازمانی که ساختار ساده و قابل پیش‌بینی می‌خوان؛ وقتی که تیم توسعه با رویکرد سنتی آشنا و نیاز به شفافیت بین لایه‌ها داریم کجا استفاده نکنیم: در پروژه‌هایی که نیازمند مقیاس‌پذیری بالا یا تغییرات مداوم هستند و همچنین در مواردی که ساختار سیستم بسیار پیچیده و وابستگی‌ها زیاد است. چون افزایش تعداد لایه‌ها گاهی انعطاف را کم می‌کنه. ————————————————— معماری سرویس‌گرا(Service Oriented Architecture - SOA) تمرکز: ارائه سرویس‌های مستقل که از طریق رابط‌های استاندارد با هم تعامل می‌کنند. کجا استفاده کنیم: در سازمان‌هایی که سرویس‌های مختلفی دارند و می‌خوان اونها رو در سیستم‌های متفاوت به اشتراک بزارن. خوراک یکپارچه‌سازی سیستم‌های مجزا و ایجاد قابلیت تعامل بین بخش‌های مختلف سازمان هست. کجا استفاده نکنیم: در پروژه‌های کوچک یا متوسط که پیچیدگی و هزینه پیاده‌سازی SOA توجیه ندارد. همچنین وقتی نیازی به اشتراک سرویس میان چند سیستم متنوع نداریم، این معماری پیچیدگی غیرضروری ایجاد می‌کنه. کلا ادای کول ها رو درنیارید و زمان ی که میخواین ماشین حساب بنویسین نرین سراغش ————————————————— معماری مایکروسرویس (Microservices Architecture) تمرکز: تقسیم سیستم به سرویس‌های کوچک، مستقل و قابل استقرار جداگانه که از طریق APIهای سبک (مثل rest api) با هم در ارتباطند کجا استفاده کنیم: در سیستم‌هایی با مقیاس بزرگ که نیاز به انتشار و تغییرات سریع دارند، تیم‌های توسعه جداگانه روی بخش‌های مختلف کار می‌کنن و بخش‌های مختلف سیستم باید به شکل مستقل مقیاس‌پذیر باشن. ولی مواظب باشین که تعدادش یهو نره بالا که از اونور(نگهداریش) به دردسر میفتین کجا استفاده نکنیم: در پروژه‌های کوچک یا تیم‌های کم تجربه که نگه‌داشت و هماهنگی بین تعداد زیاد سرویس‌های مستقل می‌تواند سخت باشه. همچنین اگر نیازمندی‌ها ساده است و تغییرات کم هستند، مایکروسرویس می‌تواند پیچیدگی غیرضروری ایجاد کند ————————————————— معماری رویداد-محور (Event-Driven Architecture) تمرکز: تبادل اطلاعات و واکنش سرویس‌ها بر اساس Eventها و پردازش ناهمزمان. کجا استفاده کنیم: در سیستم‌هایی که رویدادها و اتفاقات به صورت لحظه‌ای رخ میدن، نیاز به پاسخ آنی و مقیاس‌پذیری بالا دارن (مثل سیستم‌های IoT، بازی‌های آنلاین، پردازش تراکنش‌های لحظه‌ای). کجا استفاده نکنیم: در سیستم‌هایی که روابط همزمان، قوی و فرآیندهای خطی و ساده دارند و افزایش پیچیدگی به واسطه پیام‌ها و صف‌ها ارزش افزوده‌ای ندارد. کلا هرجایی که حرف از stream و online بودن معنی نداره ————————————————— معماری تمیز (Clean Architecture)، شش ضلعی (Hexagonal) یا پیازی (به قول یکی از بچه ها پوست پیازی) (Onion) تمرکز: جداسازی منطق کسب‌وکار از جزئیات زیرساختی و رابط کاربری، تا بشه منطق اصلی را مستقل از تکنولوژی‌ها و فریم‌ورک‌ها نگه داشت. البته تو جزئیات باهم تفاوت هایی دارن کجا استفاده کنیم: در پروژه‌های بلندمدت و پیچیده که پایداری منطق کسب‌وکار مهم است و ممکن است نیاز باشد فناوری‌های زیرساختی طی زمان تغییر کنند. یعنی مثلا یهو از SQL Server بخواین سوییچ کنین به mongoDb بی دلیل!:) کجا استفاده نکنیم: در پروژه‌های سریع و کوچک با نیازهای ساده که ایجاد این سطح از انتزاع ممکنه زمانی که دارین را هدر بده و پیچیدگی غیرضروری اضافه کنه یه چیزی درست کردین هی کپی پیست نکنین تو پروژه های مختلف همچین کاری از یه جایی به بعد شمارو تبدیل میکنه به کدنویس نه برنامه نویس @DevTwitter | <MahDi/>

Understanding HTTP status codes is crucial for web developers. Here’s a list of 18 essential status codes you need to know:

یه مقاله خوب برای دونستن انواع دیتابیس های مخلتف https://blog.algomaster.io/p/15-types-of-databases

Author: Nafiseh Ofoghi - linkedin #nest

Author: Iman Hosseini Pour - linkedin #nest

#nestjs + یک فریم ورک قدرتمند http که از ترکیب express به صورت پیش فرض و fastify به صورت آپشن + فریم ورک های بالا رو به صورت انتزاعی ارائه میده ولی دسترسی برای توسعه هم باز گذاشته + معماری صحیح بک اند اصلی ترین چالشی بود که این فریم ورک توی بک اند حل کرد که این نوع معماری رو از انگولار الهام گرفته این پست آبدیت میشود....

وقتی توی دنیا پر از اطلاعات پراکنده هستیم ِ سعی میکنم مطالبی که توی وب مفید در مورد جاوا اسکریپ به روز هست رو اینجا جمع کنم برای همین لینک میفرستم