I don’t see why. Connection-wise, the node event would loop make I/o blocking from the http request / response side a non issue. I doubt the backend is doing physics heavy stuff for the front end.
There is still considerable overhead turning things into buffers and back. Was there ever a good reason given as to why passing an object to a worker normally has to convert everything to string and back? It is just so completely idiotic.
Comments
I don’t see why. Connection-wise, the node event would loop make I/o blocking from the http request / response side a non issue. I doubt the backend is doing physics heavy stuff for the front end.
You must perform physics calculations on the backend if they are significant features that influence player positions.
Node also only works off a single core.
Node of course can work on multiple cores, using worker threads [1]. You can even share large data efficiently using a SharedArrayBuffer.
[1]: https://nodejs.org/api/worker_threads.html
It isn’t trivial to just split up a game into múltiple worker threads and keep everything in sync. With Go, it’s much easier.
Can you expand on the low hanging fruit of splitting a game into multiple goroutines?
What lends itself well to this?
goroutines
There is still considerable overhead turning things into buffers and back. Was there ever a good reason given as to why passing an object to a worker normally has to convert everything to string and back? It is just so completely idiotic.
I see. That makes sense.