Как я понял, вы хотите реализовать SSR с парсингом JSON на сервере, а затем гидрировать это на клиенте? Если так, то такой подход довольно распространён.
Однако возникает вопрос: как в таком случае вы планируете обрабатывать динамические элементы интерфейса — такие как порталы, модалки и прочие компоненты, которые могут быть добавлены или удалены из DOM по мере взаимодействия?
Я встречал похожую реализацию, например, с BDUI на базе Next.js — так что почему бы и нет. Хотя стоит отметить, что тема SSR на Node достаточно холиварная и дискуссионная. Кому-то такой подход в принципе не подходит.
В случае с PWA мы, например, не стремимся выносить логику на сервер — зачем, если основная идея в том, что пользователь «устанавливает» приложение как аналог мобильного, а всё кешируется на уровне service worker’ов?
Как вы собираетесь грузить такую систему с минимальным количеством кода? И даже если каким-то чудом у вас получится — как вы будете масштабировать это решение на десяток продуктовых команд?
А теперь добавим унифицированную платформу, где вместе с вебом живёт и мобильная разработка. И разработчиков там ещё больше, потому что нужно поддерживать две кардинально разные платформы.
И тут появляется основной барьер для быстрой доставки кода — релизы.
В результате ваше «минималистичное» решение превращается в тот самый ужас, о котором вы и пишете. Вы можете с этим мириться, можете отрицать, но отрицание — это всего лишь одна из стадий принятия неизбежного.
Как я понял, вы ориентируетесь на замеры в локальной среде без сетевых ограничений. 15 секунд закладывается на загрузки с учётом условий мобильной сети у реальных пользователей. В таких условиях получить 1 секунду — невозможно. Указанные 30% — это показатели, снятые с мобильных устройств.
Обсуждать скорость загрузки в контексте статьи — всё равно что обсуждать сферического коня в вакууме. Всё, конечно, упирается в размер JSON и итогового JS-бандла: чем больше логики и кода, тем дольше загрузка.
Тем не менее, никого ни к чему не призываю и не пытаюсь переубедить. Было бы интересно узнать про ваш опыт с BDUI, если есть: какие цифры получались у вас и что для этого делали.
На демо-стенде показало 30% прирост к скорости. Точных цифры могут варьироваться в зависимости от реальных условий и объёма данных на живом проекте. Плюс по перфоманс профайлу есть видимость, что сборщик мусора срабатывает реже, что тоже ускоряет загрузку.
В статье рассматривается концепция BDUI. Безусловно, подход спорный, но на практике многие компании в той или иной форме применяют его, что позволяет им существенно бустить производительность разработки.
Понятно, что если у вас чистая PWA без нативного мобильного приложения, то BDUI, скорее всего, вам не нужен. Однако в мультиплатформенной среде он может дать ощутимую выгоду.
Теперь по поводу вашего комментария. Могли бы вы подробнее рассказать, каким образом вы планируете реализовать описанную вами логику в рамках BDUI? Допустим, у вас есть JSON, описывающий интерфейс. Как именно вы собираетесь разделить этот JSON на каркас (skeleton/layout) и остальную структуру?
Обратите внимание, что этот же JSON используется и нашей мобильной командой. Унификация данных между платформами помогает нам существенно ускорять внедрение новых фич и снижать дублирование логики.
Потому что с yup/zod и прочими гораздо удобнее работать. Начиная вопроса расширения валидаторов, написания кастомных правил валилации и заканчивая поддержкой typescript-a из коробки.
Само решение подразумевает, что у вас есть кастомные валидаторы и кастомные правила валидации. Иначе в нём нет никакого смысла берёте Orval и там всё из коробки работает. На счёт того, как вы будете домен описывать, тут уже всё индивидуально. Нам хватает связки formik плюс yup, возможно вам нужно, что-то более многослойное. Вообщем без знания конкретных вводных очень тяжело что-то посоветовать.
Как я понял, вы хотите реализовать SSR с парсингом JSON на сервере, а затем гидрировать это на клиенте? Если так, то такой подход довольно распространён.
Однако возникает вопрос: как в таком случае вы планируете обрабатывать динамические элементы интерфейса — такие как порталы, модалки и прочие компоненты, которые могут быть добавлены или удалены из DOM по мере взаимодействия?
Я встречал похожую реализацию, например, с BDUI на базе Next.js — так что почему бы и нет. Хотя стоит отметить, что тема SSR на Node достаточно холиварная и дискуссионная. Кому-то такой подход в принципе не подходит.
В случае с PWA мы, например, не стремимся выносить логику на сервер — зачем, если основная идея в том, что пользователь «устанавливает» приложение как аналог мобильного, а всё кешируется на уровне service worker’ов?
Вы не учли важный момент: инструменты всегда выбираются из контекста задачи.
Когда мы говорим о достаточно большом объёме JavaScript-кода, за такими решениями, как правило, стоят нетривиальные проблемы.
Давайте порассуждаем. Представим трейдинговую платформу с:
реалтайм-обновлениями через WebSocket,
REST API,
банковскими формами,
фича-флагами
и прочий «радостью».
Как вы собираетесь грузить такую систему с минимальным количеством кода?
И даже если каким-то чудом у вас получится — как вы будете масштабировать это решение на десяток продуктовых команд?
А теперь добавим унифицированную платформу, где вместе с вебом живёт и мобильная разработка. И разработчиков там ещё больше, потому что нужно поддерживать две кардинально разные платформы.
И тут появляется основной барьер для быстрой доставки кода — релизы.
В результате ваше «минималистичное» решение превращается в тот самый ужас, о котором вы и пишете. Вы можете с этим мириться, можете отрицать, но отрицание — это всего лишь одна из стадий принятия неизбежного.
Как я понял, вы ориентируетесь на замеры в локальной среде без сетевых ограничений. 15 секунд закладывается на загрузки с учётом условий мобильной сети у реальных пользователей. В таких условиях получить 1 секунду — невозможно. Указанные 30% — это показатели, снятые с мобильных устройств.
Обсуждать скорость загрузки в контексте статьи — всё равно что обсуждать сферического коня в вакууме. Всё, конечно, упирается в размер JSON и итогового JS-бандла: чем больше логики и кода, тем дольше загрузка.
Тем не менее, никого ни к чему не призываю и не пытаюсь переубедить. Было бы интересно узнать про ваш опыт с BDUI, если есть: какие цифры получались у вас и что для этого делали.
На демо-стенде показало 30% прирост к скорости. Точных цифры могут варьироваться в зависимости от реальных условий и объёма данных на живом проекте. Плюс по перфоманс профайлу есть видимость, что сборщик мусора срабатывает реже, что тоже ускоряет загрузку.
Сори, тег не туда ушёл, не уследил. Вторая статья на хабре, я только учусь)
В статье рассматривается концепция BDUI. Безусловно, подход спорный, но на практике многие компании в той или иной форме применяют его, что позволяет им существенно бустить производительность разработки.
Понятно, что если у вас чистая PWA без нативного мобильного приложения, то BDUI, скорее всего, вам не нужен. Однако в мультиплатформенной среде он может дать ощутимую выгоду.
Теперь по поводу вашего комментария. Могли бы вы подробнее рассказать, каким образом вы планируете реализовать описанную вами логику в рамках BDUI? Допустим, у вас есть JSON, описывающий интерфейс. Как именно вы собираетесь разделить этот JSON на каркас (skeleton/layout) и остальную структуру?
Обратите внимание, что этот же JSON используется и нашей мобильной командой. Унификация данных между платформами помогает нам существенно ускорять внедрение новых фич и снижать дублирование логики.
Потому что с yup/zod и прочими гораздо удобнее работать. Начиная вопроса расширения валидаторов, написания кастомных правил валилации и заканчивая поддержкой typescript-a из коробки.
Само решение подразумевает, что у вас есть кастомные валидаторы и кастомные правила валидации. Иначе в нём нет никакого смысла берёте Orval и там всё из коробки работает. На счёт того, как вы будете домен описывать, тут уже всё индивидуально. Нам хватает связки formik плюс yup, возможно вам нужно, что-то более многослойное. Вообщем без знания конкретных вводных очень тяжело что-то посоветовать.
Конкретно мы у себя используем 3.0.1 версию. Но вообще кажется, что статья подходит для любой третий версии OpenAPI.
Встречались) chatgpt отлично это умеет делать.