Is the structure and development process of a browser game correct?

Question

Node.js

In general, we are planning a small browser game with multiplayer and slu.. goodies =)
Input:
I have experience of commercial development in C#. Hence, JS in its pure form with a prototype-based style is not appealing, the TypeScript syntax is more to my liking . Well, and as an IDE, respectively, painfully familiar Visual Studio Community .
The project itself is logically divided into 3 child projects:
- the client part (most likely in the form of a single-page application) - Backbone.JS
- the server part on sockets - Node.JS
- the game client (it will be loaded by the client part, but to simplify the development process I take it out as a separate project ) - Phaser
How it works:
The user logs in to the site, and then goes to the page with the game. When authorizing, we open a socket connection, which we subsequently "pick up" in the game.
I see the project structure as follows:

Solution/
--libs/
----typings/
----node_modules/
--client/
----app/
------static/
------views/
------models/
------collections/
------app.ts
----index.html
--server/
--game/
----states/
----prefabs/
----app.ts

Where

• libs folder - all dependencies used by projects (decided not to produce one in each individual project).
  
• the server part will partially borrow the logic of the client part (I can’t outline the file structure for sure yet)
  

Actually, the main question:
The organization of the client side is tormenting: leave it as it is, or modify it as follows:

--client/
----app/
------modules/
--------demo-module/
----------static/
----------views/
----------models/
----------collections/
------app.ts
----index.html

That is, split into (in) dependent modules (for example, the same game is a separate module). Such a split seems quite logical, but I'm afraid that with the growth of the project, this approach may cause difficulties with the growth of dependencies between modules (after all, we do not live in a fairy-tale world when we manage to create completely independent ones).
Actually, the main question is in the structure of the application and the rationality of the chosen tools, the approach to implementation.
Well, of course:
I would be grateful for reasoned criticism and advice
P. S:: I
don’t want ASP.NET as a backend and I know about Angular

Answer 1

1. on the server side, we make Api (for everything where web sockets are not required) + web sockets. I would advise you a compiled language if the game plans to have 100k+ (for example, the wonderful golang language)
2. Phaser is replaced with a set of js classes that work with your API
3. If you need a "fast interface" then use libcanvas + nativeJS jquery case) + learning to use open source.
4. The folder structure is not particularly important.
In general, a one-pager can be done in an evening. And we do all the animations with css or libcanvas

Answer 2

The structure is approximately standard, the client can be divided into modules. Phaser is not quite a professional tool, but it is possible. As for the backbone, it depends on the amount of client logic, and the planned support, and also on the size of the team. The more logic and the smaller the command, the worse BB will behave (then you need to choose a framework, Angular is not the only solution). The folder structure is not so important, correct it in the process of refactoring.
Vladimir Grabko : Phaser is not for API, but for rendering, physics, etc.