Aspnetcore-angular-universal: ASP.NET Core + Node Vs. just Node for a horizontally scalable SSR front-end microservices.
Hey, this as an awesome project, cheers to you for such a huge contribution.
can I have any feedback on these arguments?
- with a non-monolithic architecture, and developers who are as familiar with Node, I don't see any advantages for having ASP.NET Core host the Angular renderer.
- performance should be about the same, because at the end of the day, node is doing the server rendering, Kestrel and ASP.NET Core are just handling request with the pipeline and routing etc.
- biggest factor in perf is I/O, (SS)Rendering/string interpolation.
- I/O in my case are just GraphQL queries to build a ngrx-Apollo store and serialize it (the goal).
- NPM ecosystem is just as good, IMHO, arguably better than Nuget for finding a lot of good packages for routing etc.
- with only Node.js, Universal and Express, you won't have IPC that should be faster.
- ASP.NET Core, runtime and packages, Node+Angular services package seem to be unnecessary in this case and an additional points of failure and hassles.
- finding good Docker/Kubernetes images with just Node.js can be much easier.
wis
All 2 comments
Hey Wesam!
So for a lot of people, it'd be much easier to just have a fairly simple Node server that handles the serialization / SSR. The performance would be about the same (maybe even a smidgen faster). Personally, I typically go the Node-route myself, and if I'm using aspnet or anything for APIs, then those are separate processes.
with a non-monolithic architecture, and developers who are as familiar with Node, I don't see any advantages for having ASP.NET Core host the Angular renderer.
Advantages are more-so for people who have large mono-repo projects and want to include an Angular SSR application, and utilize all of the Auth / Tools / Libraries (dotnet ones) they have access to already.
performance should be about the same, because at the end of the day, node is doing the server rendering, Kestrel and ASP.NET Core are just handling request with the pipeline and routing etc.
biggest factor in perf is I/O, (SS)Rendering/string interpolation. I/O in my case are just GraphQL queries to build a ngrx-Apollo store and serialize it (the goal).
Performance is about the same yes. If you're going to use GraphQL and such you'll have a much easier time in Node-land.
NPM ecosystem is just as good, IMHO, arguably better than Nuget for finding a lot of good packages for routing etc.
No denying that! You can find much more in npm.
with only Node.js, Universal and Express, you won't have IPC that should be faster.
Goes along with the performance we talked about, yes it'd be a tiny bit faster. Of course the RPC that Steve built is extremely fast, but not having that, makes life a little bit simpler!
ASP.NET Core, runtime and packages, Node+Angular services package seem to be unnecessary in this case and an additional points of failure and hassles.
These are nice additions to have if let's say you're adding section that aren't Angular, some reporting aspnet mvc section / etc. These could of course just be done in another project, but some people just like to keep things simple.
finding good Docker/Kubernetes images with just Node.js can be much easier.
Very true, although this one can be put in a Docker image fairly easily as well.
In general, if you're comfortable enough with Node, I'd say go the Node starter route (check out our Angular-CLI + Universal & Node starter here: https://github.com/angular/universal-starter)
If you want all the nice-ities of the Aspnet ecosystem (inside of your Angular project, as in you want to pass things down from the Controller -> Node -> Angular) then use something like. Soon we'll be moving this to a better version that Steve has worked on that uses the Angular-CLI (and wraps aspnet around it, similarly to how things are done here).
I hope that helps with your decision!
MarkPieszak
on 14 Dec 2017
Feel free to fork, and then maintain the suggested version, if you want to, lol. :P I do that with my little BS4 fork of the project.
Adondriel
on 21 Dec 2017
Related issues
ketrex2
路
18Comments
isaacrlevin
路
24Comments
georgiosd
路
26Comments
MarkPieszak
路
41Comments
consigliory
路
29Comments
Most helpful comment
Hey Wesam!
So for a lot of people, it'd be much easier to just have a fairly simple Node server that handles the serialization / SSR. The performance would be about the same (maybe even a smidgen faster). Personally, I typically go the Node-route myself, and if I'm using aspnet or anything for APIs, then those are separate processes.
Advantages are more-so for people who have large mono-repo projects and want to include an Angular SSR application, and utilize all of the Auth / Tools / Libraries (dotnet ones) they have access to already.
Performance is about the same yes. If you're going to use GraphQL and such you'll have a much easier time in Node-land.
No denying that! You can find much more in npm.
Goes along with the performance we talked about, yes it'd be a tiny bit faster. Of course the RPC that Steve built is extremely fast, but not having that, makes life a little bit simpler!
These are nice additions to have if let's say you're adding section that aren't Angular, some reporting aspnet mvc section / etc. These could of course just be done in another project, but some people just like to keep things simple.
Very true, although this one can be put in a Docker image fairly easily as well.
In general, if you're comfortable enough with Node, I'd say go the Node starter route (check out our Angular-CLI + Universal & Node starter here: https://github.com/angular/universal-starter)
If you want all the nice-ities of the Aspnet ecosystem (inside of your Angular project, as in you want to pass things down from the Controller -> Node -> Angular) then use something like. Soon we'll be moving this to a better version that Steve has worked on that uses the Angular-CLI (and wraps aspnet around it, similarly to how things are done here).
I hope that helps with your decision!