<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Neel-Vekariya</title>
    <description>The latest articles on DEV Community by Neel-Vekariya (@neel-vekariya).</description>
    <link>https://dev.to/neel-vekariya</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3968256%2Ff900b976-6eab-4295-bca9-6c8b6fd937e2.jpeg</url>
      <title>DEV Community: Neel-Vekariya</title>
      <link>https://dev.to/neel-vekariya</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/neel-vekariya"/>
    <language>en</language>
    <item>
      <title>Scheduling Mechanisms In Node.js Execution.</title>
      <dc:creator>Neel-Vekariya</dc:creator>
      <pubDate>Sat, 06 Jun 2026 05:07:10 +0000</pubDate>
      <link>https://dev.to/neel-vekariya/scheduling-mechanisms-in-nodejs-execution-5gb0</link>
      <guid>https://dev.to/neel-vekariya/scheduling-mechanisms-in-nodejs-execution-5gb0</guid>
      <description>&lt;p&gt;Many developers think Node.js runs async code in the order it appears in the file. It doesn’t.&lt;/p&gt;

&lt;p&gt;Execution order depends on synchronous code, &lt;code&gt;process.nextTick()&lt;/code&gt;, microtask queue, and event loop phases.&lt;/p&gt;

&lt;p&gt;When code runs, different types of work go into different queues. Like &lt;code&gt;nextTick()&lt;/code&gt;, promise microtasks, and phase-based queues in the event loop.&lt;/p&gt;

&lt;p&gt;First, Node.js runs all synchronous code. Things like &lt;code&gt;console.log()&lt;/code&gt; or normal function calls. Only after that it starts dealing with queued work.&lt;/p&gt;

&lt;p&gt;&lt;code&gt;process.nextTick()&lt;/code&gt; runs first. It has higher priority because Node.js uses it for internal and critical callbacks that need to run right after sync code, before promises.&lt;/p&gt;

&lt;p&gt;After that, microtasks (mainly Promises) are executed.&lt;/p&gt;

&lt;p&gt;Once both are cleared, the event loop moves into its phases like timers, I/O callbacks, and check phase.&lt;/p&gt;

&lt;p&gt;Between these phases, Node.js again checks &lt;code&gt;nextTick()&lt;/code&gt; and microtasks. If anything is pending there, it runs them before continuing.&lt;/p&gt;

&lt;p&gt;That’s basically how Node.js decides what runs first and what runs later.&lt;/p&gt;

</description>
      <category>javascript</category>
      <category>architecture</category>
      <category>learning</category>
      <category>node</category>
    </item>
    <item>
      <title>Why await Doesn't Block Node.js</title>
      <dc:creator>Neel-Vekariya</dc:creator>
      <pubDate>Fri, 05 Jun 2026 07:23:39 +0000</pubDate>
      <link>https://dev.to/neel-vekariya/why-await-doesnt-block-nodejs-e10</link>
      <guid>https://dev.to/neel-vekariya/why-await-doesnt-block-nodejs-e10</guid>
      <description>&lt;p&gt;A common misconception is that &lt;code&gt;await&lt;/code&gt; makes Node.js sit idle until an operation completes.&lt;br&gt;
Consider a database query that takes 200ms.&lt;br&gt;
Many developers imagine the JavaScript thread spends those 200ms waiting for the response. That's not what happens.&lt;/p&gt;

&lt;p&gt;When an async function reaches an &lt;code&gt;await&lt;/code&gt; statement, execution of that function is paused. The underlying operation continues through the database client and operating system I/O mechanisms while the event loop remains available to process other work.&lt;/p&gt;

&lt;p&gt;Once the query result arrives, Node.js schedules the continuation of the async function and resumes execution after the &lt;code&gt;await&lt;/code&gt;.&lt;br&gt;
This execution model allows a single Node.js process to manage thousands of mostly I/O bound requests without dedicating a thread to each connection.&lt;/p&gt;

&lt;p&gt;Limitation&lt;/p&gt;

&lt;p&gt;This benefit applies primarily to I/O bound workloads.&lt;br&gt;
CPU intensive operations such as image processing, large JSON transformations, encryption, or complex calculations still execute on the JavaScript thread. When CPU work dominates request processing, event loop responsiveness decreases and concurrency suffers.&lt;/p&gt;

&lt;p&gt;Understanding this distinction is critical when evaluating Node.js scalability.&lt;/p&gt;

</description>
      <category>webdev</category>
      <category>javascript</category>
      <category>node</category>
      <category>backend</category>
    </item>
  </channel>
</rss>
