Should I use an isomorphic application in a high-load e-commerce project?

Question

go

Hello everybody.
I work as a backend developer (golang) in one fairly large e-commerce project, previously worked as a full-stack developer. The project itself is similar in functionality to ozon.ru, that is, it aggregates goods from different suppliers. Now this is an angular web application without a normal SSR, the client pulls a bunch of js noodles and it all works slowly and sadly.
I sketched an mvc framework on go, and wrote a prototype in which I render pages on the server and give static html with very small js (only for ajax search, filtering, I tried to drive everything out with css). The speed of work is cosmic, page refresh is not even noticeable to the eye. In addition, my framework periodically polls the backend and caches the results in memory (I also store page templates in memory), which also speeds it up and makes it more fault-tolerant.
But when I proposed this project, a real holivar began. All front-end developers say that this is old and not fashionable, there is no best practice, and in general they can make an isomorphic application with SSR, and everything will be fine and they will beat 100 out of 100 page speed calmly.
All my arguments, including that JS is a priori slower than Go and does not support multithreading, there is no normal OOP, and that the client does not need to be loaded with tons of JS for the sake of full AJAX, and in general development will become easier and faster, they dispute.
I would like to know the impartial opinion of knowledgeable people, in the long run, which solution will actually show itself better?

Answer 1

1. Angular game, to display hello-world you need to build a rocket, and for everything else there are providers. 2. In addition to angular, there are more convenient frameworks, vue
/ react / svelte
3. Without SSR, it’s sad that your site will not be found (google will find it)
into 1 huge file. But there would be a desire and direct hands.
5. SPA can be written fast, the main thing is not to litter any rubbish like jquery / sliders / and other 100+kb of shit
6. Comparing client js and server go is rather strange
7. "you don't need to load the client with tons of JS for the sake of full AJAX" yes, kick the fronters
8. "And in general, development will become easier and faster" at the prototype level, maybe yes, but in the future? Generate everything for each page request, or just load the template and data?
To this I remembered the phrase: Yes, I could easily piss to the toilet from here, but I'm too lazy and that's why I pissed
But since you started, then finish it, in the end there are both MPA and SPA applications that are quite alive and well
And yes , add SSR

Answer 2

In the long run, the one that will be easier to maintain.
If your bike is uploaded for sale, then the rest of the developers will need to delve into all this, plus support and development, plus all possible future problems - all this will have to be cut by hand and from scratch. Also, the architecture must be well prepared, and you must clearly show this, and given that initially everyone will be against it, then convincingly prove it.
If your front-end developers have now created some kind of application in Angular that is buggy and slow, then this is primarily a problem for developers. If they have faked angular, where everything has already been decided for them, a bunch of community docks and ready-made answers to any problems, then there is a high probability that your bike will be faked with even greater speed.
Your approach is better if:
1) your load actually exceeds what can be squeezed out of angular by doing everything correctly (bundles, ssr, caching, dependency optimization, etc.)
2) your front-end team is swayed enough to cut a complex vanilla JS project and squeeze more out of it what can be squeezed out of the framework (this is very difficult)
What can be done:
- identify real problems
- determine the criteria for solving them (speed, size, page speed, and so on)
- determine the time for which the team is ready to optimize the angular application to the desired parameters
If they don’t - Raise the question again, showing your version.
In any case, it will be difficult to push a bike, there are quite serious objective reasons why this should not be done, the benefits should significantly exceed the minuses, and this must be proven to everyone.
Plus, there is a high probability that your developers want "fashionable youth" on "modern technologies" - this is already a human factor and it will be the most problematic.

Answer 3

I write backend in Go. The first step is to design the API and data structures. Frontenders tell me which URI they want to receive which JSON and my job is to provide that quickly and reliably. How they are going to render this JSON to me is not particularly interesting.

no need to load the client with tons of JS

strongly disagree. There are many clients and one server. The computing power of modern clients is often greater than the power of the server. Therefore, I believe that as much work as possible should be shifted to the client.

Answer 4

All my arguments, including that JS is a priori slower than Go and does not support multithreading, there is no normal OOP, and that the client does not need to be loaded with tons of JS for the sake of full AJAX, and in general development will become easier and faster, they dispute.

In general, the speed of the language on the web is not critical.
Full of high-load projects in slow languages.
For the main delays do not depend on the language - this is the network and the DBMS (and other operations associated with disks).
However, when the server is loaded with a very large number of clients and / or with very complex processing logic (but not related to the DBMS / disks, but tied only to the processor), the speed of the language already matters.
What about you? What exactly is the bottleneck?
Well, from a business point of view, it doesn't matter what to do.
It is only important how many free hands you have, familiar with this or that technology.
If there is a load on the servers, then even this may not be critical, if it is advisable for the business to simply buy more servers, because the developers are not cheap and this is the time they will do it.
With simple logic - yes.
With complex logic - not everything is so obvious.

Answer 5

Do not force the server with client code!
Render everything on the server. cache and give to the client.
Next, use the front to load the data.
What pluses:
1. 1 connection to a database.
2. 1 static file that will fall into the cache.
3. 1 static file will be indexed by search engines.
4. The token is checked 1 time, not for every sneeze of the frontend

Answer 6

Isomorphism gives a boost only in cases of normal crud + almost complete coincidence of entities from the back and front. This is suitable for satiks ordering pizza, or making an appointment for a haircut. But not for something medium / large.

Answer 7

Rendering pages in Go is not the best idea in my opinion. Plus, why do you need to do work that, as I understand it, does not fall into your area of ​​\u200b\u200bresponsibility? For to understand this and use it is not for you, but for front-end developers (who have a very popular framework that barely works).
If this is an analogue of ozon.ru, then it is possible to peep the stack at the ozone itself? Write the backend in Go, and let the front-end developers write in Node.js + Nuxt.js + Vue.js, then you will have a fast backend, the ability to render on the server side, and isomorphism, and a human js-framework for the front.
PS Well, Angular is really a game.