Corporate software engineering is a world within itself. Huge codebases, often containing spaghetti code, call for a statically typed language that helps to maintain sanity when working on such complex projects. This used to be the case for a long time – Java and C# used to be the two kings of this domain, ruling with no real competitor in sight.
Many enterprises use frameworks such as Express.js, Fastify or Nest.js on the server-side, and React, Angular or Vue on the client-side. They don’t stop there either. React Native/NativeScript often serve them when creating mobile apps. Electron allows them to create desktop apps. Even though they have the resources to have dedicated teams working in native languages for all platforms, they choose not to. Why?
Additionally, there is the economic benefit of smaller spending since the teams are smaller.
How was PayPal able to reduce the number of developers?
Nowadays, developers working on both sides of an application are more common, and they enjoy certain popularity. They can save big companies a lot of money while the app maintains the same level of quality.
As a result, there are fewer team members and overall a smaller number of teams required.
That’s just the beginning of the advantages - enterprises enjoy many other benefits from adopting Node.js.
Not only that – the app could serve twice the amount of requests versus the Java based application. Interestingly, the Node.js app utilized only one of the cores, while Java used… 5 of them [sic!]. If you are not impressed by now, pages were served 200ms faster.
Node.js in general does not require many resources to run and is quite fast. ITMAGINATION’s Artur Łabudziński in a conversation with us, shared how he is impressed by the language's performance and Google’s great work on their V8 engine – the foundation of Node.js.
Since 2013, there were a lot of improvements made to the language, and runtime, which most likely further improved performance.
Up until a few years ago, the general approach for enterprises was to build apps using a monolithic architecture. To put it simply, all parts of the app were closely dependent on each other, leading to an important problem. If one part of the app failed, all of the app failed.
That is one of the primary reasons corporate teams started embracing the microservices architecture. All parts of the app were separate, thus if one feature stopped working, the app remained functional. There are two primary ways the separation is achieved – containers and serverless functions.
When teams are looking to make their apps more independent from the environment from which they are working, they turn to containers. They still require some consideration as to what and where they run, though not that much. In general, containerization is a reliable way to ensure we remove the very well-known problem with software engineering - “but it runs on my computer”.
Serverless functions are another step in abstracting the “where” away. Solutions, such as Azure Functions or AWS Lambdas are a bit radical in separating features and functions. They are also traditionally preferred by corporate users. In fact, in 2020, around 80% of AWS users from bigger companies use Lambdas. The biggest users embrace them heavily, as debugging can be an issue that is not worth it for the smaller teams, but fault tolerance, isolation, and is heavily desired by the bigger teams. They scale better, are quicker to deploy, and we can avoid any lock-ins.
To end with, serverless functions are about the most cost efficient from all microservices solutions, as one pays only as much as one uses instead of paying up front for a month.
To give a simple example of problems that could have occured, should TypeScript have not been created:
If in C#, you write
Nothing will compile, and you won’t be able to evaluate the expression, because you get an error. Using a plus is fair game in C#, since it’s string concatenation. Using a minus will get you in trouble. Fair enough.
In Python we cannot use plus or minus.
This simple code will not run correctly, because we will get a “TypeError.”
is 111 and 10 respectively. No errors, no problems.
The answer is: nothing at all. We would get an error when compiling our code, and our editor would complain as well.
In the case of TypeScript, the benefits largely outweigh any possible negatives . Simplicity, speed, cost-efficiency. All while maintaining (design-time) type safety. To be clear, what are the possible drawbacks of adopting the superset?
Node.js, faster than other alternatives, and more approachable as well, is consistently getting faster and faster, being the corporate gateway to microservices. Its alternative, Deno, might also get love from the big companies, however it’s perhaps too early to determine whether it’s going to give Node.js a run for its money.
Next up, 5 Reasons Why Startups Love Node.js!