NestJS Is Basically ASP.NET Core, And That's Great!
Not clickbait, I swear. Hear me out. Let's drop some dates first:
ASP.NET 5 was announced in mid-late 2015
ASP.NET Core was RC'ed in January 2016 and released in June 2016.
NestJS 1.0's first NPM publish date was May 14, 2017.
Now that we have the chronological order out of the way, you see why I worded the title the way I did. It's not "ASP.NET Core Is Basically NestJS" because that would infer that NestJS came first -- it did not.
Now that we have the controversy handled, let's look at the similarities and some differences. At the end I'll offer my opinion on when to use one or the other.
|Accept incoming HTTP requests and route them to responsible services.
|In both frameworks, these can represent repositories, helpers, factories, etc. Services can be dependency-injected into other services and controllers.
|In NestJS, modules are meant to organize "closely related set of capabilities". In ASP.NET, Namespaces usually organize by type of class. These are different, but both serve as a way to organize the codebase.
|Process request and response objects.
|Filters in ASP.NET are used for a variety of things, including what NestJS uses pipes for.
|Authorization Filters in ASP.NET are the same as Guards in NestJS.
|Essentially the same functionality. Convert a thrown exception into a response user can understand.
|Incoming payload validation
|REST endpoint versioning
Just looking at the above table, you can see the two frameworks cover all the bases. There are more similarities I have omitted, or this table would get out of control. For example both frameworks support websockets, gRPC, unit testing, graphql, response caching and auth.
Both frameworks use the concept of inversion of control (the D in SOLID) and just generally are very object-oriented. Anyone coming from ASP.NET Core and strongly typed C# would feel right at home in NestJS with TypeScript. It's a natural transition.
NestJS supports CRON-based tasks. ASP.NET Core's BackgroundTask does not support cron expressions.
NestJS's database ORM support is cool. ASP.NET has EntityFramework which is okay. They're not quite the same thing but do share the same goal -- simplify data access.
NestJS has specific implementations for microservices. ASP.NET supports different transports, but not out of the box.
NestJS supports delegation of long-running or CPU-intensive tasks to queues (Redis-backed) via Bull. It's cool that this is built-in, I don't believe ASP.NET has anything out of the box.
Note: It's interesting that out of the popular REST API frameworks, ASP.NET Core is by far the fastest (14) with Fiber (Go) coming in in 34th spot and nothing else in the top 100. Also, these benchmarks don't really matter.
ASP.NET Core's integration testing framework with TestServer is arguably better than anything Jest can offer.
ASP.NET Core has a giant corporation behind it and millions of dollars in resources. NestJS is run by a single guy (not really, but you get the picture).
These differences are largely irrelevant, except, perhaps, for the CRON task support in NestJS. There are Nuget packages which improve BackgroundTasks in ASP.NET Core, but they're not available out of the box.
I'm Starting a Business, Which Should I Use?
As with everything in life, it depends. Do you have a team? What is your team's competency? Do you want enterprise-level support when the time comes? Where will you host?
If you're bootstrapping a hipster world-altering startup out of your garage, NestJS is the better choice. Assuming you don't need any kind of audit compliance any time soon and you're okay with refactoring later when you join the big leagues.
If you're building something in a regulated industry (aerospace, health, finance), and you're planning to bring in more seasoned and serious engineers who take security and performance seriously, I recommend ASP.NET. There's a reason these huge industries run on enterprise-supported languages like Java and C# and not Node.
You may also consider Gin or Fiber (Golang) if you're writing microservices. If you're writing anything real-time like a game server, you won't be using Node, ASP.NET or Go anyway.
In the end, this is not a very high-stakes choice. Look at the big picture and make the call. You won't be disappointed with either choice!
Did you find this article valuable?
Support Paul K by becoming a sponsor. Any amount is appreciated!