<story><title>We 30x&apos;d our Node parallelism</title><url>https://blog.plaid.com/how-we-parallelized-our-node-service-by-30x/</url></story><parent_chain><item><author>spamizbad</author><text>The only way this makes sense to me is if they have to contend with lots of expensive parsing, event sequencing, and throttling requirements. Payment APIs, bank websites, etc can be quite byzantine. I could understand how one might code yourself into a corner with a monolithic node app and basically just say &amp;quot;F-it, we&amp;#x27;re doing this synchronously!&amp;quot;&lt;p&gt;I don&amp;#x27;t even think it&amp;#x27;s a terribly &lt;i&gt;bad&lt;/i&gt; thing to do assuming it favors feature velocity.... but at that point, I&amp;#x27;d recommend moving away from Node towards something like Python. And if you wanted to dip your toes back into async plumbing land, explore Go or Elixir.</text></item></parent_chain><comment><author>sho</author><text>&amp;gt; explore Go or Elixir&lt;p&gt;I have never seen a good argument for using golang for business logic. If you are writing &lt;i&gt;the actual server&lt;/i&gt; then sure, use golang. If you are writing some high-speed network interconnect, use golang. Some crazy caching system, sure use golang. The public WS endpoint, use golang.&lt;p&gt;But if you need to access a DB with golang for anything more than, like, a session token, then you made the wrong choice and you need to go back and re-assess.&lt;p&gt;Elixir is in the &amp;quot;germination phase&amp;quot; and I predict massive adoption in the next 5 years. It is a truly excellent platform, every fintech company I know at least has their toe in the water. Everyone I show this video to [1] just says &amp;quot;well, shit.&amp;quot;&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=JvBT4XBdoUE&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=JvBT4XBdoUE&lt;/a&gt;</text></comment>
<story><title>We 30x&apos;d our Node parallelism</title><url>https://blog.plaid.com/how-we-parallelized-our-node-service-by-30x/</url></story><parent_chain><item><author>spamizbad</author><text>The only way this makes sense to me is if they have to contend with lots of expensive parsing, event sequencing, and throttling requirements. Payment APIs, bank websites, etc can be quite byzantine. I could understand how one might code yourself into a corner with a monolithic node app and basically just say &amp;quot;F-it, we&amp;#x27;re doing this synchronously!&amp;quot;&lt;p&gt;I don&amp;#x27;t even think it&amp;#x27;s a terribly &lt;i&gt;bad&lt;/i&gt; thing to do assuming it favors feature velocity.... but at that point, I&amp;#x27;d recommend moving away from Node towards something like Python. And if you wanted to dip your toes back into async plumbing land, explore Go or Elixir.</text></item></parent_chain><comment><author>bjacokes</author><text>You hit the nail on the head here. When N different API requests simultaneously time out – all because a ramda.uniq call in one of them received an array of 100,000 nested objects – it&amp;#x27;s easy to make a spot code fix, but harder to systematically prevent it from happening in the future. There aren&amp;#x27;t really linters for &amp;quot;bad event loop blockage&amp;quot;. Code reviews are the main tool we have, but you&amp;#x27;d be surprised what sorts of logic can trickily block the event loop. For API reliability and development velocity in the short-term, by far the easiest approach was to throw more infrastructure at the problem.&lt;p&gt;We do use Go for almost all of our other services, and there are an increasing number of integrations written in Python. But we&amp;#x27;re still using and investing in our Node integrations code for the foreseeable future, and this was an important step for simplifying our infrastructure.&lt;p&gt;We certainly hope the tooling and rollout process in the post were instructive for anyone using Node, even if their stacks were pristine from day 1 and never need this sort of complex migration :)</text></comment>