Комментарии 7
Максимальный комфорт веб-приложений, когда рендером страниц занимается клиент, а не сервер. Нет, вы не подумайте, я сам люблю в Remix потыкать хобби ради, но если что-то продуктовое, то пожалуй оставлю связку React ( любой возьмите ) + Nest.js ( любой возьмите ). Под задачи быстродействия всего вот этого очень много лет строилось обвязка, производителями браузеров, поставщиками веб-серверов, фреймворков.
А так спасибо за SSR фреймворк, все будут юзать Next.js, как и юзали до этого.
«Посмотреть на результат работы tramvai-приложений можно на https://www.tbank.ru/.»: формирование страницы сервером — более трети секунды. В сравнении с временем формирования страниц у приличных сайтов, где оно исчисляется единицами-десятками миллисекунд — неприлично долго.
То есть быстродействие этого примера системы — ну уж очень низкое.
Мне сложно сказать, так как не знаю что и с чем сравниваете, но предполагаю два варианта:
- приличный сайт это статичный блог
- или это клиентский рендеринг
Сравнивать отдачу статичного HTML из CDN с динамической страницей не очень корректно.
Если говорим про CSR - более валидной метрикой будет LCP, сложно назвать полноценным ответом быстрый показ двухсекундного лоадера для пользователя.
Прикольно видеть синтаксис модулей Angular и jsx в одном фреймворке, крутая работа! :)
Вопрос про экшены: если идет запрос на какой-то "секретный" API, который может отрабатывать дольше лимита и который не хотим светить клиенту, как в таком случае происходит перезапрос?
Спасибо за фидбек!
Для такого вида запросов механизм перезапроса не будет применяться, защита тут возможна на нескольких уровнях:
- указать экшену что он должен запускаться onlyServer
- в env переменной API указать что на клиент ее передавать не надо
- вообще код экшена в клиентский бандл не включать
Простой альтернативы Server Actions некста например у нас нет, можно создать API роут и его как BFF юзать но это надо делать вручную.
Tramvai — фреймворк для создания веб-приложений