Moving from Node.js to .NET Core

Moving from Node.js to .NET Core

In this article, we’ll talk about going from Node.js to .NET Core, by exploring some key differences we noticed as we ported some targeted REST API endpoints.

In this article, we’ll talk about going from Node.js to .NET Core, by exploring some key differences we noticed as we ported some targeted REST API endpoints.

Here on Visual Studio** App** Center, our platform is built as a set of microservices, which has afforded teams to make language and platform choices that work best for them, and ultimately allowed us to move and iterate quickly. Over time, two distinct stacks have emerged:

As we have continued to merge our teams and do more and more cross-team work, it’s become apparent that we should settle on a single choice and unify so that jumping between services is less jarring. The fact that a lot of our customers run non-Windows platforms, and our team runs a mix of Mac, PC, and Linux, led us to explore a new direction.

**Enter .NET Core **

We started investigating .NET Core as a solution because of the cross-platform abilities it offered, and the fact that it works great with VS Code, our cross-platform development solution. We felt like .NET Core allowed us to preserve this flexibility, but not continue diverging our code base, with some new services written in TypeScript, and others in **C# **on the .NET Framework. This allows us more flexibility when moving work between teams as well. We could have also gone with **TypeScript **but given the skill set of the majority of the team (C#) and the pain we have seen managing Node.js dependencies, we decided on .NET Core. We’ll discuss the dependency issue in more detail later in this post. For more information on .NET Core, see the docs.

Our goal with this post isn’t to convince you that .NET Core is better than Node.js: we made our decision primarily based on the skill sets of our team. Instead, we want to share the things that we noticed as we have been starting the porting work, in the hope that if you’re embarking on a similar journey, this information will be helpful. If you’re curious about direct comparisons regarding performance, this site is a good resource that is constantly updated. The .NET Core entry on that list is called aspcore. Another interesting post explores saturating 10GbE at 7+ million request/s using .NET Core.

Also, note that for the purposes of this post we aren’t looking at specific **TypeScript **features, and on our team, we continue to use **TypeScript **for new front-end development as there are many benefits to having concrete types on top of JavaScript.

The Challenge

We are not embarking on a re-write of all services, but aside from having all new services run on .NET Core targeting AKS, we are looking for opportunities to port over problematic code from either the .NET Framework or Node.js. In this blog post we’ll talk about going from Node.js to .NET Core, by exploring some key differences we noticed as we ported some targeted REST** **API endpoints. For our take-aways, we are mainly focused on the developer experience, and not necessarily on performance benchmarks or other orthogonal concerns.

Key Take-Aways We Noticed

Porting code into a strongly typed language takes time

In our existing **TypeScript code base, we take advantage of dynamic types frequently, and in the C# version of the code we had to define more concrete types. Additionally, the code that we were porting specifically dealt with bit masks, so translating those concepts between JavaScript and C# presented some pain for us. One of the main things we lost was easy parsing of JSON and dynamic object graphs. .NET Core includes JSON parsing out of the box, but it isn’t quite as native as what JavaScript **provides.

Another thing that came up was the need to create more mapping types instead of relying on dynamic mapping, which we didn’t have to handle as much since we were already in TypeScript, but if you are coming from a straight JavaScript** **project this is something else you will want to consider.

All in all, if you embark on this journey, be prepared to invest the appropriate amount of time on model classes and other scaffolding that you will need for a successful transition.

String comparison differences

In JavaScript, when doing case insensitive string comparisons, we tend towards doing  toLowerCase() prior to doing a ===, where we don’t care about case. Generally speaking, the equivalent C# code uses string.Equals  and passes in a StringComparison  enum value to indicate how to handle issues of case sensitivity. A common case is scenarios where you do not care about case and locale, and for those you should use StringComparison.OrdinalIgnoreCase. Here are some useful references for other scenarios that may arise:

A concrete example of porting where both examples return success under the same conditions:

JavaScript:

var desiredValue = 'someValue';
 
if (envVar && envVar.toLowerCase() === desiredValue.toLowerCase()) {
 
  console.log('Success!');
 
 
}

Equivalent C#:

var desiredValue = "someValue";
 
if (string.Equals(envVar, desiredValue, StringComparison.OrdinalIgnoreCase)) {
 
  Console.WriteLine("Success");
 
}

Fewer dependencies in .NET Core

One thing that has been nice is to manage fewer dependencies (and a shallower dependency tree) in the .NET Core version of the code, and hopefully this means it will be easier to maintain. We have struggled with keeping dependencies up to date and managing many dependencies in our Node.js projects. Additionally, **developers **on our team prefer NuGet’s policy of “lowest matching version” rather than npm’s encouragement to use “highest matching patch” or “highest matching minor version” (using the ~syntax in package.json by default via npm i). We recognize this is a philosophical difference and opinions on this may vary. The pros of the NuGet approach are more control and explicitness, whereas the npm approach allows for theoretically non-breaking changes to be easily applied.

Other Thoughts

There isn’t one right answer, and the purpose of this post isn’t to convince you one way or another, just to shed some light on the process we have gone through recently as a team. As we discover and do more in **.NET Core **on **AKS **we will be sure to share along the way!

Top 7 Most Popular Node.js Frameworks You Should Know

Top 7 Most Popular Node.js Frameworks You Should Know

Node.js is an open-source, cross-platform, runtime environment that allows developers to run JavaScript outside of a browser. In this post, you'll see top 7 of the most popular Node frameworks at this point in time (ranked from high to low by GitHub stars).

Node.js is an open-source, cross-platform, runtime environment that allows developers to run JavaScript outside of a browser.

One of the main advantages of Node is that it enables developers to use JavaScript on both the front-end and the back-end of an application. This not only makes the source code of any app cleaner and more consistent, but it significantly speeds up app development too, as developers only need to use one language.

Node is fast, scalable, and easy to get started with. Its default package manager is npm, which means it also sports the largest ecosystem of open-source libraries. Node is used by companies such as NASA, Uber, Netflix, and Walmart.

But Node doesn't come alone. It comes with a plethora of frameworks. A Node framework can be pictured as the external scaffolding that you can build your app in. These frameworks are built on top of Node and extend the technology's functionality, mostly by making apps easier to prototype and develop, while also making them faster and more scalable.

Below are 7of the most popular Node frameworks at this point in time (ranked from high to low by GitHub stars).

Express

With over 43,000 GitHub stars, Express is the most popular Node framework. It brands itself as a fast, unopinionated, and minimalist framework. Express acts as middleware: it helps set up and configure routes to send and receive requests between the front-end and the database of an app.

Express provides lightweight, powerful tools for HTTP servers. It's a great framework for single-page apps, websites, hybrids, or public HTTP APIs. It supports over fourteen different template engines, so developers aren't forced into any specific ORM.

Meteor

Meteor is a full-stack JavaScript platform. It allows developers to build real-time web apps, i.e. apps where code changes are pushed to all browsers and devices in real-time. Additionally, servers send data over the wire, instead of HTML. The client renders the data.

The project has over 41,000 GitHub stars and is built to power large projects. Meteor is used by companies such as Mazda, Honeywell, Qualcomm, and IKEA. It has excellent documentation and a strong community behind it.

Koa

Koa is built by the same team that built Express. It uses ES6 methods that allow developers to work without callbacks. Developers also have more control over error-handling. Koa has no middleware within its core, which means that developers have more control over configuration, but which means that traditional Node middleware (e.g. req, res, next) won't work with Koa.

Koa already has over 26,000 GitHub stars. The Express developers built Koa because they wanted a lighter framework that was more expressive and more robust than Express. You can find out more about the differences between Koa and Express here.

Sails

Sails is a real-time, MVC framework for Node that's built on Express. It supports auto-generated REST APIs and comes with an easy WebSocket integration.

The project has over 20,000 stars on GitHub and is compatible with almost all databases (MySQL, MongoDB, PostgreSQL, Redis). It's also compatible with most front-end technologies (Angular, iOS, Android, React, and even Windows Phone).

Nest

Nest has over 15,000 GitHub stars. It uses progressive JavaScript and is built with TypeScript, which means it comes with strong typing. It combines elements of object-oriented programming, functional programming, and functional reactive programming.

Nest is packaged in such a way it serves as a complete development kit for writing enterprise-level apps. The framework uses Express, but is compatible with a wide range of other libraries.

LoopBack

LoopBack is a framework that allows developers to quickly create REST APIs. It has an easy-to-use CLI wizard and allows developers to create models either on their schema or dynamically. It also has a built-in API explorer.

LoopBack has over 12,000 GitHub stars and is used by companies such as GoDaddy, Symantec, and the Bank of America. It's compatible with many REST services and a wide variety of databases (MongoDB, Oracle, MySQL, PostgreSQL).

Hapi

Similar to Express, hapi serves data by intermediating between server-side and client-side. As such, it's can serve as a substitute for Express. Hapi allows developers to focus on writing reusable app logic in a modular and prescriptive fashion.

The project has over 11,000 GitHub stars. It has built-in support for input validation, caching, authentication, and more. Hapi was originally developed to handle all of Walmart's mobile traffic during Black Friday.

Hire Node JS Developer from Expert Node JS Development Company

Hire Node JS Developer from Expert Node JS Development Company

NodeJS Development Company-Hire Node JS developer from the most prominent NodeJS development company, Mobiweb and get remarkable Node.js app development services.

Are you looking to hire the most talented and expert Node JS developers for your valuable web application projects and mobile app development projects or you want to migrate application on Node JS framework? Then you have to hire Node JS developer from leading offshore Node JS development company Mobiweb Technologies. We have a team of developers with extensive experience in developing Node JS based applications whether it is web based or mobile app based.

Difference between AngularJS, React, Ember, Backbone, and Node.js.

The most common thing between all of them is that they are Single Page Apps. The SPA is a single page where much of the information remains the same and only some piece of data gets modified when you click on other categories/option.