Досі не розумію, як вони зібрались вирішити цю задачу.
В інтернеті є петабайти англійскього тексту і навіть прімитивними алгоритмами можна навчити машину розуміти той текст. Тому що він однозначний і його дуже багато, на всі випадки життя. А от в програмуванні на кожну з мов нема петабайт тексту. Більш того, ті гігабайти розділені на фреймворки, кожен з котрих може бути повною шизою чергових абстракцій. Нема в них тих обємів для навчання.
Тож програмувати щось набагато складніше пінг-понга, який скоріш за все ШІ зкопіював десь з гітхабу, наврядчи зможе в найближчій перспективі.

від чого збивається scroll position

Це я виправив, скрол тепер не збивається.
Доречі дякую за фідбек, цю штуку давно хотів виправити,
тож фідбек був гарний аргумент зробити це зараз.
Код мінявся на рівні платформи, тож всі існуючи проєкти на платформі
отримали це виправлення автоматично.

лайки не ставить, коментарі не відправляються

Я це зробив, аккаунт «Testing»

Доречі, цей баг щойно виправив.

Мене все частіше дивує платформа. Буває за звичкою ниряєш десь під капот, дебажити складну внутрішню логіку платформи, думаєш що там щось зламали останні коміти, а потім розумієш, що все що потрібно було .... підправити джисон.
Сказати що юзер з ролю User, має право писати в масив Likes в Security dimension.
І це все.

"Likes": {
        "Allow": {
          "Write": [
            "User"
          ]
        },

github.com/...​adc167074bf0cff457e6eb28e

Схоже саме і так буде виглядати справжнє програмування майбутнього.
Кілька сотень рядків красивого функціонального коду, плюс конфігурація бд в джисонах і складний сайт працює.

Це я до того що кеш це добре, але лише там де він потрібний, якщо в нас немає проблеми з швидкістю відкриття аккаунта користувача то для чого його кешувати?

Там весь сайт, наче мене зновую підєднали до модему dial up який пакети передає через аналоговий телефон зі швідкістю 33,6 кбіт/сек. Ні одна сторінка не відкривається швидко.

Майже 3 секунди на завантаження сторінки. Мабуть ми маємо на увазі якісь різні кеші.
fraplat.com/...​143a1bce64d2ef2001029.png
Ваш кеш бігає на Плутон і назад, схоже.

Дякую звичайно за аналіз нашої аудиторії та бази даних, але чому тоді 10% самих активних, чому не 90% самих пасивних які не міняються?

То треба трохи в Computer Science, чому саме так. Теорія ймовірності.
Розподіл Парето. І оце ось все.

А кейс коли людина відправляє коментар більше ніж 255 символів теж ігноруємо? Пароль до 6 символів чи до 8? Писав би я веб апп для програмістів то можливо б і закрив на це очі, але ми пишемо сайти для людей яким потрібний хороший UX, моментальне реагування на введені дані та підказки.

Я все ще не бачу проблеми провалідувати це на сервері. Тим паче по секуріті, фронт валідація нічого не вартує, все одно потрібно дані всі перевіряти на сервері повторно.

Я це зробив, аккаунт «Testing»

Добре, я протестую. Але треба розуміти, що кількість рядків в проєкті, а саме 450 майже на все — суттєво не зміниться після виправлення багу. Тобто ми зараз більше займаємося QA тестуванням, а не парадигмою правильної зрозумілої архітектури.
UTube майже весь колись був написаний за добу з купою функціоналу
dou.ua/...​rums/topic/44975/#2694913

450 рядків в сучасному Реакт в вашому проєкті, мабуть тільки код одного банера більше займає. Звідси і читаємость коду, гнучкість коду, кількість багів в коді, щоб це не означало.

Там скоріш всього параметр проганяється через escape, тобто екранує спец символи.
Це не спрацює, або в фейсбуці дійсно сидять трейні.

Я це з нашого робочого проекту (myminifactory.com) взяв, мільйони користувачів

От з вашого робочого проєкту. Перша ж сторінка в анонімній вкладці. Відкрив раз, відкрив два, візуально вони однакові. (чи майже однакові?) То чому цей кейс, коли сторінка відкривається перший раз не кешувати?

мільйони користувачів, повідомлень між ними

З тих мільйонів 10% активні, 90% заходять може раз в тиждень, чи раз в місяць. То чому сторінки для 10% самих активних не кешувати? Далі повідомлення. Чому не кешувати повідомлення користувачів? Навіщо то все кожен раз перераховувати.
Тим паче, в связці фронт-бек база автоматично вміє відслідковувати що змінилося в реактивному стилі, це не коштує в розробці — нічого.

лайки не ставить, коментарі не відправляються

Тому що треба зареєструватися та залогінитися.
Гості не можуть лайкати відео. Коли реєструєшся там відкривається купа функціоналу.

немає клієнтської валідації

Тому що вона не потрібна на клієнті. Кейс коли юзер намагається відправити пустий коментар, це скільки таких випадків серед реальних користувачі ? 0,1% ?
Нехай в цьому випадку нагружає сервер валідацією, то не є проблема.

збивається scroll position

Це не важко зробити, ця задача є в беклозі та буде працювати не на рівні коду, а на рівні платформи.

UX жахливий

А цей myminifactory.com який обвішаний банерами та вспливаючими модальними вікнами наче сайт для дорослих з 90х це не жахливий UX ? )

Коли Реакт появився, всі плювалися від того що в один файл знову запихнули CSS, HTML та JS. Я теж плювався. Всі роки і практики до цього розповідали як потрібно все розділяти. Але нічого, все чудово працює зараз.

Запити в БД пишуться і виконуються на сервері. Просто тепер не треба створювати напряму окремо сервіс який робитиме запити. По суті до CSS, HTML, JS додали ще і запити в БД, але так додали що цей код завжди виконується і залишається на сервері.

Це погане рішення, яке згодом знову перепишуть.

Тобто на сервері ми тримаємо мільйони pre-rendered _user_view.html, мільярди умовних _transacton_row.html і ще сотні компонентів які можуть виглядати по різному в залежності від того хто їх переглядає та які параметри передані

Звідки взялись мільйони та мільярди строрінок ? Можна конкретний а не сферичний приклад сайту ? Там точно не можна нічого оптимізувати ? Наприклад на доу буде макс 500 найбільш переглядаємих сторінок в данний момент, які поновлюються в кеші.

можна посилання на проект з таким рендерингом

Так, можна посилання,
dou.ua/forums/topic/44975

Але є один проєкт, який я вважаю доволі «дорослим». Це портал Fractal Platform. На сьогодні він моделює функціональність Jira, Slack, має свій блог. У нього інтегровані засоби для деплою та моніторингу програм Fractal Cloud, а також безліч звітів, портал для навчання та проходження іспитів студентами. Усе це навантажує складну систему прав на 12 розділів. Весь UI перекладено 7 мовами. Загальна доменна модель, за оцінками, перевищує 300-350 реляційних таблиць.
Із якою швидкістю має працювати такий застосунок? На це питання складно відповісти, але сьогодні це близько 100 мс на завантаження будь-якої сторінки. А на розігрітому кеші час падає до 12-15 мс.

Скрін i.imgur.com/uWqzZbx.jpg

Ну і як виглядає «Реакт майбутнього», а точніше його заміна.
В 450 рядків коду виписаний майже весь фронт-бекенд функціонал на сайт схожий на ютуб
(реєстрація канали підписки лайки коментарі завантаження відео)

fraplat.com/jupiter/UTube

І так, там теж є запити до бази данних прямо з коду, майже як зараз хочуть зробити в Реакт
github.com/...​UTube/UTubeApplication.cs

Але є ньюанс, не лише це має бути зроблено. А коли буде зроблено через 10-15 років все що потрібно, то нарешті застосунки будуть мати не 20 тис рядків коду на подібний сайт, а в ті самі 400 рядків коду. Та латенсі буде не 500 мс, а в районі 100-150 мс навіть без кешування сторінок. А з кешуванням 14 мс як на скріні вище.

Команди розділились на фронт і бек, кожен знає свою область відповідальності. Чому ми тепер йдемо на сервер знову

Тому що це політичні лозунги для роздування штату, а не сухий виважений розрахунок.
В багатьох додатках цей поділ штучний. Ще можна зрозуміти, що бекендер ніколи не зможе гарно малювати дизайн, але коли бекенд і фронтенд все що роблять, перепаковують та валідують одній й тіж самі моделі данних до та після рест апішечки, дублюючи логіку — в цьому немає ніякої доцільності, крім ускладнення проєкту.

Невже не легше було вирішити ті проблеми які є в SPA, а по суті їх лише 3 — SEO, дублікація логіки валідації даних на фронтенді і бекенді та time to first meaningful paint?

Їх не можна вирішити.

Не кажучи вже про цілу низку інших проблем, чисто архітектурного характеру коли єдиний вузел в системі перевантажений саме генерацією динамічного HTML та є вузьким місцем в системі.

Але є ньюанс
1. В статті є контр приклад з Moment.js, де серверу необхідно відправити на клієнт 72 кб. При серверному рендерінгу можна самому все порахувати, та відправити кілька байт як готовий результат.
2. Сервер часто генерує однакові сторінки, та має багато можливостей для кешування та обчислення що називається "не відходячи від каси"©. Перекладати однакову одноманітну роботу на тисячу пристроїв, як мінімум не схвалюють екологи, та виробники батарей для мобільних пристроїв.

Трохи занятно спостерігати, як Реакт наче сліпе котеня, намацує правильний шлях.
Може через 10-15 років буде там де Фрактал вже зараз.
1. Фронт рендерінг
2. Сервер рендерінг
==> Ви знаходитись з Реактом тут <==
3. Сервер та клієнт мають майже однакові БД та спілкуються діфами, замість велосипедування рест апі. Результат: Зменшився обєм коду, зменшився трафік, зросла швидкодія в рази.
4. Оскільки сервер та клієнт повністю знайшли спільну мову, тепер працюють магічні технології, коли база данних відслідковує зміни данних від яких залежать рендерені веб сторінки. Це дає змогу випльовувати вже готові рендерені сторінки за мілісекунди, якщо данні на них не змінились або змінились частково в базі.
5. Енжин навчився генерувати готові веб сторінки використовуючи лише модель данних в базі, що скоростило обєм роботи для круд аплікацій в десятки разів.

В підсумку, що реакт девелопери тільки не видумують, щоб захистити своє право писати в 10-100 разів більше коду, який значно гірше підтримується та повільніше працює. Вони вже інтуітивно розуміють, що там де вони зараз сидять, всидіти довго не зможуть. Але нормально подумати та скласти той весь пазл з фронт-бек-та базою разом не можуть.
Заважає інерційність, "а какжє так"© А вот так.

Скажіть, будь ласка, як ви це бачите?

Що саме бачу? Якщо взяти весь стек вашого коду на Джава
1. На рівні процесору там все кешується в лінійках кешу
2. На рівні дискової системи, все кешується на рівні контроллера.
3. На рівні бази данних там все кешується в своїх локальних кешах
4. І ось прийшов ваш рівень, рівень доменного обєкту і ви такий, нє нє нє ... це не по принципам ДДД бо база данних має бути окремо від домена. Рілі? Яке відношення має одне до іншого. Любий рівень в вашому стеку спроєктований так як спроєктований, та не суперечить доменній архітектурі, тому що купа доменних обєктів що інкапсулюють в собі купу бізнес логіки.

Можете, будь ласка, проілюструвати кодом або псевдокодом:

доменний клас Task з методом UpdateStatus
ентіті TaskEntity
перетворення TaskEntity в доменний клас Task
Можу запропонувати взяти свій репозиторій за основу, але ви, здається, на C# пишете.

Ця задача просто не цікава, вона академічна.
Напишіть в тасці Update Tasks Set Status = Done where ParentId = Id, головне щоб для клієнтського коду нічого не змінилось. Тобто якщо визиває Task.Done(); то виконувалась вся необхідна робота з сабтасками за кулісами.

Давайте, будь ласка, не буде відволікатись на оптимізації, справа не в них.

Справа в них. Ви чомусь обговорюєте оптимізації, тому що вам не подобається, що щось в вас повільно завантажується і намагаєтесь перекласти відповідальність на ДДД.

Чи буде він завантажувати при цьому сабтаски (і сабтаски сабтасок)?
Якщо так — це погіршить перформанс для кейсів, коли це непотрібно.
Якщо ні — як тоді виконується UpdateStatus(Done)?

Хто вам заважає не завантажувати весь доменний обєкт. Часткого кешувати, використовувати проксі патерн. Зберігати каунтер в паренті як я вже приводив приклад, зберігати лише айдішники і тільки їх рекурсивно обходити. Це якось суперечить ДДД ? Від того Task перестав бути доменним обєктом що вміє обробляти свої сабтаски мовчки ? Перестав мати бізнес логіку всередині себе? Наче ні.
То що ми зараз обговорюємо?

Повертаємося до початку.

Архітектура і алгоритми це різні речі.

Яка різниця як воно реалізовано всередині. Тут вже що найменьше 3 оптимізації були описані. І ще можна 100500 оптимізацій придумати, щоб воно взагалі за мілісекунди працювало.
Архітектура DDD це про те, що доменний обєкт Task.UpdateStatus(Done) вміє всередині переводити саб таски в Done. Як він це робить — це вже його проблеми. DDD на це питання не має відповідати. DDD лише відповідає на питання, що всі хто працює з Task — не повині писати зайвого коду для обробки Sub Task на своєму рівні, вся ця логіка інкапсульована в доменному обєкті.
І це все.

Але щоб викликати ChildNode.UpdateStatus всередині Domain Object треба, очевидно, його туди якось завантажити, ні?

Очевидно що ні. Щоб обновити статус вам треба знати лише Id сабтаски, та статус в який ви її переводите. Вся інша інфа зайва в памяті в вашому контексті.

А оце мене, власне, і цікавить. Як, наприклад, зробити такий юзкейс — примусове переведення таски (і всього графу її підтасок) в DONE — в стилі DDD?

Навіщо грузити граф?
Класика, коли ви викликаєте Node.UpdateStatus, це також викликає у всіх ChildNode.UpdateStatus всередині Domain Object.
Розумію що ви натякаєте на якісь Bulk Update, але той балк буде ефективнішим коли в вас тих 500 сабтасок. Але судячі з вашої задачі то біт оптимізація, тож в вас є всі шанси лишити красиву DDD ієрархію.

dou.ua/forums/topic/44975

За допомогою GPT я змогла реалізувати цей проект всього за тиждень!

Це звісно добре, що ви витратили тиждень з GPT, але як і в цій темі
dou.ua/forums/topic/45944
те що ви робили тиждень, можна було написати за 15 хвилин і 15 рядків коду.
При умові використання правильних інструментів, звісно.
github.com/...​x2/Sandbox2Application.cs

Проєкт що калькулює ціну пального, може бути корисним для подорожуючих,
створено та задеплоєно поки закіпав чайник.
fraplat.com/jupiter/Sandbox2

За тиждень (5 днів) можна вже написати клон UTube десь на 10-15 скрінів,
там десь 450 рядків коду + дизайн,
fraplat.com/jupiter/UTube

Висновок: GPT + сучасні методи розробки (Python, Java і тп) це дуже не ефективні засоби розробки і мене дуже дивує терпіння та наполегливість людей, котрі то все використовують.
Я дуже лінивий, тому GPT не використовую для програмування, віддаючи перевагу правильним інструментам а не генератору токенів на неефективних мовах програмування.

Я бачу проблему в тому, що, якщо в доменному класі Task є сабтаски — то це вдарить по перфомансу (витягувати всю ієрархію), а якщо нема — то робота с сабтасками буде в сервісному шарі, що ламає всю концепцію. Як вийти з цього протиріччя?

Архітектура і алгоритми це різні речі.
Оптимізацію можна зробити в реактивному стилі, наприклад коли в сабтасці статус Done, вона звертається до свого Parent та робить інкремент ++subTasksDone. Коли subTasksDone == countSubTasks статус парента Done.

На все це ніяк не впливає DDD, доменний обєкт інкапсулює свою логіку роботи, його контракти від внутрішніх оптимізацій не змінюються.

Це до мене питання? Перечитайте уважніше мій пост.
Я всього лиш дав референц, що не потрібно це нижче обговорювати. Це як обговорювати асемблер, можна, але навіщо. Тут я лише щоб показувати прийоми програмування, які дійсно скорочують обєм робіт в 10-100 разів за рахунок правильної архітектури, та правильних абстракцій.