<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های omid.saifpanahi1991</title>
        <link>https://virgool.io/feed/@omid.saifpanahi1991</link>
        <description></description>
        <language>fa</language>
        <pubDate>2026-04-15 04:25:12</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/3813/avatar/pZaJYY.png?height=120&amp;width=120</url>
            <title>omid.saifpanahi1991</title>
            <link>https://virgool.io/@omid.saifpanahi1991</link>
        </image>

                    <item>
                <title>ساخت فریمورک nodejs</title>
                <link>https://virgool.io/@omid.saifpanahi1991/%D8%B3%D8%A7%D8%AE%D8%AA-%D9%81%D8%B1%DB%8C%D9%85%D9%88%D8%B1%DA%A9-nodejs-mswssccri4a4</link>
                <description>یکی از بهترین کارها برای یادگیری Node.js ساخت یک framework بک اند هست.البته Framework که نمیشه گفت بلکه یه سری از ابزارها رو سر هم می کنیم و یک ساختار پروژه مطلوب خودمون میسازیم.فقط یه نکته رو بگم که این کار رو برای یادگیری انجام میدهیم.این تجربه تلخ رو داشتم که به خاطر منافع مالی بعضی از مدیران فریمورک هایی ساختند و همه پرسنل شرکت رو مجبور به استفاده از فریمورکی که قدیمی بود یا اصلا ساختار درستی نداشتند کردند. بنابراین هدف این تمرین فقط یادگیری است نه قدرت نمایی.سوال هایی که تو ساخت این framework پیش میاد:۱. چرا به یک فریم ورک جدید نیاز داریم؟- آیا به performance بیشتری نسبت به Express یا NestJS نیاز داریم؟- آیا نیاز داریم که پروژه سبک تر باشد؟- آیا بر روی مایکروسرویس یا  REST یا GraphQL یا WebSocket ها تمرکز کرده ایم؟- آیا نیاز داریم که authentication و caching درونی داشته باشیم؟برای چه کسی این فریم ورک رو میسازیم؟برای خودمان، تیممان یا جامعه متن باز۲. تصمیم های معماریسیستم Routing- آیا از middleware ها مانند express یا از controller ها مانند NestJS برای routing استفاده می کنیم؟- آیا route ها dynamic یا static خواهند بود؟مدیریت middleware- آیا middleware chaining مانند app.use خواهیم داشت؟- آیا سیستم plugin برای گسترش خواهیم ساخت؟مدیریت request و response- آیا نیازه که از ماژول های native http استفاده کنیم یا آنها را wrap می کنیم؟استفاده از dependency injection- آیا مانند NestJS ماژولار یا مانند Fastify سبک خواهد بود؟مدیریت config- آیا از .env پشتیبانی خواهیم کرد؟- آیا اجازه config injection در زمان اجرا خواهیم داشت؟اجرای Async- آیا async/await کاملا پشتیبانی میشود؟- آیا معماری event-driven خواهیم ساخت؟مدیریت Error و لاگ ها- آیا پاسخ های خطا استاندارد شده خواهیم داشت؟- آیا به صورت مرکزی Logging خواهیم داشت؟۳. نکات Performanceبهینه سازی سرعت- آیا از http.createServer استفاده می کنیم یا آن را wrap می کنیم- بهینه سازی مدیریت Event loopتوزیع بار و clustering- آیا باید از چند process پشتیبانی کند؟- آیا پشتیبانی داخلی از Worker thread ها و ماژول cluster دارد؟مدیریت حافظه- جلوگیری از memory leak در middleware- استفاده از performance hooks برای benchmarking۴. نکات مقیاس پذیریمایکروسرویس ها و سیستم های توزیع شده- آیا نیازه که IPC و WebSocket و gRPC پشتیبانی شود؟مدیریت database- آیا از ORM خاصی مانند Prisma یا TypeORM استفاده می کند یا انتخاب آزاد است؟سیستم Caching- آیا cache داخل حافظه دارد؟- آیا برای static content پاسخ ها را cache می کند؟کارهای background- آیا از Kue/BullMQ برای کارهای پسزمینه استفاده می کند؟۵. نکات امنیتی- سیستم درونی JWT- استفاده از middleware برای CORS یا Rate Limiting- برای جلوگیری از SQL Injection و XSS چکار می کنیم؟تست نویسی و Debugging- آیا از فریم ورک test خاصی استفاده می کنیم؟- آیا از structured logging استفاده می کنیم؟نسخهبندی و API stability- آیا از API Versioning پشتیبانی می کند؟- آیا استراتژی برای backward compatibility داریم؟</description>
                <category>omid.saifpanahi1991</category>
                <author>omid.saifpanahi1991</author>
                <pubDate>Tue, 11 Mar 2025 23:29:15 +0330</pubDate>
            </item>
                    <item>
                <title>واسه یادگیری و تمرین git</title>
                <link>https://virgool.io/@omid.saifpanahi1991/%D9%88%D8%A7%D8%B3%D9%87-%DB%8C%D8%A7%D8%AF%DA%AF%DB%8C%D8%B1%DB%8C-%D9%88-%D8%AA%D9%85%D8%B1%DB%8C%D9%86-git-u5suafcldosg</link>
                <description>واسه یادگیری و تمرین git یه چیزی پیدا کردم که خیلی خوبه خودم تمام تمرین های local رو انجام دادم و باید بگم با حال بود، خوشم اومد ازش...لینکش رو اینجا می‌ذارم شما هم استفاده کنید...</description>
                <category>omid.saifpanahi1991</category>
                <author>omid.saifpanahi1991</author>
                <pubDate>Mon, 23 Sep 2024 11:27:28 +0330</pubDate>
            </item>
                    <item>
                <title>What is a REST API?</title>
                <link>https://virgool.io/@omid.saifpanahi1991/what-is-a-rest-api-obv409srhxq1</link>
                <description>A REST API (Representational State Transfer Application Programming Interface) is a set of rules that allows different software systems to communicate over the internet using HTTP requests.🌐 Key Concepts:Stateless: Each API call is independent, and the server doesn’t store client data between requests.HTTP Methods: Uses standard methods like:GET: Retrieve dataPOST: Submit new dataPUT: Update existing dataDELETE: Remove dataResource-Based: Resources (like users, posts, or products) are represented by URLs, and the actions on these resources are performed using HTTP methods.🔗 Why Use REST API?Simple: Easy to understand and implement.Scalable: Ideal for handling multiple clients (e.g., mobile, web apps).Flexible: Works with different formats like JSON, XML.</description>
                <category>omid.saifpanahi1991</category>
                <author>omid.saifpanahi1991</author>
                <pubDate>Sat, 21 Sep 2024 22:11:40 +0330</pubDate>
            </item>
                    <item>
                <title>API architectural patterns</title>
                <link>https://virgool.io/@omid.saifpanahi1991/api-architectural-patterns-n0ldkuew22q0</link>
                <description>API architectural patterns are essential for designing and structuring APIs effectively to meet various requirements such as scalability, maintainability, and performance. Here are some common API architectural patterns:1. REST (Representational State Transfer):- REST is an architectural style that uses standard HTTP methods (GET, POST, PUT, DELETE) to interact with resources identified by URIs. It emphasizes stateless communication and is widely used for web services due to its simplicity and scalability.2. GraphQL:- GraphQL is a query language for APIs that allows clients to request only the data they need. It provides a more flexible and efficient alternative to REST by enabling clients to specify the structure of the response, reducing over-fetching and under-fetching of data.3. SOAP (Simple Object Access Protocol):- SOAP is a protocol for exchanging structured information in web services. It relies on XML for message format and typically uses HTTP or SMTP for message transmission. SOAP is known for its robustness and support for complex transactions but can be more heavyweight compared to REST.4. gRPC (gRPC Remote Procedure Calls):- gRPC is a high-performance RPC framework that uses Protocol Buffers for serialization. It supports multiple programming languages and is designed for low-latency, high-throughput communication, making it suitable for microservices architectures.5. WebSockets:- WebSockets provide a full-duplex communication channel over a single, long-lived connection. This pattern is ideal for real-time applications, such as chat applications or live notifications, where low latency and continuous data exchange are required.6. Webhook:A webhook is a method of augmenting or altering the behavior of a web application with custom callbacks. It allows one application to send real-time data to another whenever a specific event occurs. Unlike traditional APIs, where the client must poll the server for updates, webhooks enable a more efficient and immediate communication mechanism.Each of these API architectural patterns has its use cases, advantages, and trade-offs. The choice of which pattern to implement depends on the specific requirements of the application, including performance, scalability, and ease of use.</description>
                <category>omid.saifpanahi1991</category>
                <author>omid.saifpanahi1991</author>
                <pubDate>Mon, 16 Sep 2024 13:47:45 +0330</pubDate>
            </item>
                    <item>
                <title>Comparing npm and Yarn Commands</title>
                <link>https://virgool.io/@omid.saifpanahi1991/comparing-npm-and-yarn-commands-bcwelaeaf3vi</link>
                <description>Install dependenciesnpm install =&gt; yarnInstall a packagenpm install [package_name] =&gt; yarn add [package_name]Install a package globallynpm install -g [package_name] =&gt; yarn global add [package_name]Install a package as a development dependencynpm install --save-dev [package_name] =&gt; yarn add --dev [package_name]Uninstall a packagenpm uninstall [package_name] =&gt; yarn remove [package_name]Uninstall a package globallynpm uninstall -g [package_name] =&gt; yarn global remove [package_name]Uninstall a development dependency packagenpm uninstall --save-dev [package_name] =&gt; yarn remove [package_name]Update the dependenciesnpm update =&gt; yarn upgradeUpdate a packagenpm update [package_name] =&gt; yarn upgrade [package_name]Create a new packagenpm init =&gt; yarn initRun a script defined in the package.jsonnpm run =&gt; yarn runTest a packagenpm test =&gt; yarn testPublish a packagenpm publish =&gt; yarn publishRemove all data from the cachenpm cache clean =&gt; yarn cache clean</description>
                <category>omid.saifpanahi1991</category>
                <author>omid.saifpanahi1991</author>
                <pubDate>Mon, 02 Sep 2024 13:23:23 +0330</pubDate>
            </item>
            </channel>
</rss>