shadowndacorner

You say you have a team of playtesters - do you keep them around consistently and run them through every test? Seems slightly problematic coming from a game dev perspective to always use the same people. First, in the case of escape rooms, they'll probably get better and better at rooms in general, so might not be representative of the experience of newer players. Secondly, if you keep using the same people, you might get results that are skewed positively as they grow to like the team working on the rooms (free games and all that), not to mention that they feel like they're part of the team. Those are just the two that immediately come to mind.

Anyway, you might already have a system to work these things out, or you might have found that it's not a huge issue for escape rooms. Regardless, good luck with your work!

node.js is asynchronous which enables it to address multiple requests simultaneously without blocking them

Just to be clear, any version of asp ASP since C# 4.0 shipped has a very similar style of concurrency as Node. In fact, I'm pretty sure the javascript async/await syntax was largely designed based on C#'s. Writing asynchronous code in Node before the implementation of async was absolutely atrocious - just google "node callback hell" if you're interested.

Also, you actually run into more blocking behavior in Node than you do with Asp given that Node can only process your code on a single thread at a time. I emphasize "your code" because the native libraries that power many Node libraries are multi-threaded, so when you make an async call to a library, the underlying native code likely runs on a worker thread. However all javascript/typescript must run on a single thread, compared to C# which can run any user code on multiple threads.

Here's a diagram in this article that shows the main differences: https://www.esparkinfo.com/node-js-vs-asp-net.html

Skimming this article, it's... certainly not something I'd put any stock in... Putting aside the fact that it's only really looking at the surface details of the two and attempting to compare them piecewise (which you can't really do for languages/frameworks like this), as someone who has used both in various production environments for several years now, a lot of the claims it makes are just outright false.

The organization of the article also doesn't really make any sense... One of the categories is... Benefits? What does that even mean? And it says that the winner of that category is "Node.js because you have only one code for deployment and its ability to scale applications fast." Putting aside the somewhat broken English, that makes zero sense as a qualifier. Not only can you have a monorepo (which I assume is what it means by "one code") for either, but horizontally scaling a Node backend is no easier than doing so with an Asp backend. It's also no faster to scale Node applications than it is to scale Asp applications, assuming your infrastructure is set up correctly.

To be absolutely clear though, I'm not criticizing your choice to go with Node in any way. It's a great framework, and as I said in another comment, the framework that makes the most sense for you is the one you're the most comfortable with. The only reason I asked was because your client is C#, meaning you could share code between the frontend and backend if you used Asp. But if it works well for you guys, then more power to ya!

Out of curiosity, why use node in the backend as opposed to asp if the client is C#? Do you use js or ts?

Can't speak for the former, but the latter should happen automatically. If not, you might want to consult a doctor.

It's faster for smaller requests that come in from lots of concurrent connections

Do you have any data to back up that claim? I'm not saying it's incorrect, it just isn't in line with my experience as a full stack engineer, or most of the experience I've heard from colleagues.

It also doesn't seem to make much sense theoretically afaik. While V8 is ridiculously fast for a javascript engine, it is still a javascript engine. That means that (almost) all data is stored in dictionaries, which will always take up more memory and be significantly slower to serialize, deserialize, and simply read from/write to than the binary representation you get in strongly typed languages like C# (though this is somewhat negated based on the fact that I think ASP uses reflection to fill in the controller arguments, but it might do some form of code weaving instead). This means that not only do you have higher memory pressure with more concurrent connections, but you also have higher overhead to handle any given request.

The same idea applies to real-time networking (eg working with raw sockets/websockets), except there's an even higher overhead because .NET is better able to interop with native code than Node can afaik, though I will admit I'm not super familiar with native library interop in Node and it could very well be better than I would expect. Regardless, this could be somewhat solved with very high level networking abstractions in Node libraries, though similar gains could be achieved in .NET.

Either way, the performance differences you see here shouldn't really matter too much in practice until you get to very high CCU, at which point it may make sense to shift to a lower level language anyway.