Идут годы, а я не делал Single page аппы для веба. На горизонте веб-проект и поэтому хочу понять текущую ситуацию, когда лучше Single page а когда обычное веб приложение с перезагрузкой
Здравствуйте, peer, Вы писали:
P>Идут годы, а я не делал Single page аппы для веба. На горизонте веб-проект и поэтому хочу понять текущую ситуацию, когда лучше Single page а когда обычное веб приложение с перезагрузкой
По мне всегда лучше spa, это то чего реально не хватало раньше. Только нужно готовить правильно: web api должно возвращать данные и ни чего кроме данных.
Здравствуйте, Qulac, Вы писали:
Q>Только нужно готовить правильно: web api должно возвращать данные и ни чего кроме данных.
Это и для multiple pages полезно, если они, например, хранятся на клиенте (в ресурсах). На практике это может быть, скажем, визард, у которого переходы с этапа на этап оформлены как навигация. Иногда бывает удобно что-то подобное запилить.
А вообще, я считаю, оптимально исходить из более универсального принципа: HTML это язык описания UI. Тогда правило "web api должно возвращать данные и ни чего кроме данных" не зависит от числа страниц.
В мире мудрых мыслей: «Иди на нефильтрованный там загон для врагов и щизофреников» (VladD2).
Здравствуйте, peer, Вы писали:
P>Идут годы, а я не делал Single page аппы для веба. На горизонте веб-проект и поэтому хочу понять текущую ситуацию, когда лучше Single page а когда обычное веб приложение с перезагрузкой
Современный подход это "обычное" веб приложение с компиляцией HTML на сервере и "гидрацией" на клиенте. SPA уже в прошлом, устаревшая технология. А веб-страницы как файлы — вообще древность.
Т.е. с срервера браузер получает уже готовый HTML при начальной заргузке страницы.
Это объединяет плюсы обеих подходов — элеметрарное индексирование в поисковиках, всесь текст и данные уже в HTML, никаких вызовов API на первой загрузке или мегабайтов жаваскрипта,
все уже вызвано на сервере, жаваскрипт порезан на мелкие подгружаемые кусочки (та самая гидрация), плюс кэширование страниц, плюс все возможности SPA после начальной загрузки —
обновление UI через вызовы нормального Web API и обновление на клиенте, а не через повторный рендеринг страницы (или кусков) на сервере.
см. фрреймворки типа astro, react (next), vue (nuxt), svelte
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, peer, Вы писали:
P>>Идут годы, а я не делал Single page аппы для веба. На горизонте веб-проект и поэтому хочу понять текущую ситуацию, когда лучше Single page а когда обычное веб приложение с перезагрузкой
bnk>Современный подход это "обычное" веб приложение с компиляцией HTML на сервере и "гидрацией" на клиенте. SPA уже в прошлом, устаревшая технология. А веб-страницы как файлы — вообще древность. bnk>Т.е. с срервера браузер получает уже готовый HTML при начальной заргузке страницы.
bnk>Это объединяет плюсы обеих подходов — элеметрарное индексирование в поисковиках, всесь текст и данные уже в HTML, никаких вызовов API на первой загрузке или мегабайтов жаваскрипта, bnk>все уже вызвано на сервере, жаваскрипт порезан на мелкие подгружаемые кусочки (та самая гидрация), плюс кэширование страниц, плюс все возможности SPA после начальной загрузки — bnk>обновление UI через вызовы нормального Web API и обновление на клиенте, а не через повторный рендеринг страницы (или кусков) на сервере.
bnk>см. фрреймворки типа astro, react (next), vue (nuxt), svelte
почитал немного про next.js и не понял там бэк нельзя на .net core запилить, там чисто node.js или можно сделать web api на .net core?
Здравствуйте, peer, Вы писали:
P>почитал немного про next.js и не понял там бэк нельзя на .net core запилить, там чисто node.js или можно сделать web api на .net core?
Да, ты все правильно понял, в этом и смысл этого фреймворка. nextjs без бэка это просто reactjs.
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, peer, Вы писали:
P>>почитал немного про next.js и не понял там бэк нельзя на .net core запилить, там чисто node.js или можно сделать web api на .net core?
bnk>Да, ты все правильно понял, в этом и смысл этого фреймворка. nextjs без бэка это просто reactjs.
а ты вроде на .net писал, node сложно\много времени заняло чтобы писать прилично софт?
дня 3 на изучение выделить могут.
а то с nodejs не знаком и вот думаю что взять для фронта. понравилась идея, что в next.js нет кучу непонятных левых пакетов, но вот изучать nodejs
а astro, nuxt и svelte все nodejs для бэка юзают или что-то работает с .net core?
Здравствуйте, peer, Вы писали:
P>>>почитал немного про next.js и не понял там бэк нельзя на .net core запилить, там чисто node.js или можно сделать web api на .net core?
bnk>>Да, ты все правильно понял, в этом и смысл этого фреймворка. nextjs без бэка это просто reactjs.
P>а ты вроде на .net писал, node сложно\много времени заняло чтобы писать прилично софт?
Ну да, писал, до этого на плюсах писал
P>дня 3 на изучение выделить могут. P>а то с nodejs не знаком и вот думаю что взять для фронта. понравилась идея, что в next.js нет кучу непонятных левых пакетов, но вот изучать nodejs
Ну сложного там особо ничего нет, но вообще nodejs для nextjs изучать особо не нужно, это же фреймворк, он все оборачивает.
Просмотреть курс попробовать за нескольк дней вполне норм.
P>а astro, nuxt и svelte все nodejs для бэка юзают или что-то работает с .net core?
Не, это все node.
Если под "работают с .net" имеется в виду "могут вызывать API" так это любые из них конечно, для этого вообще фреймворк не нужен (встроенные в браузер fetch уже все умеет)
Для генерации API для тайпскрипта из .net в принципе тоже ничего не нужно — nswag/swagger/swashbuckle и все будет (в смысле, автокомплит и тайпчек)
Мне понравился astro (последний проект делал на нем),
но под него несколько ограниченный выбор готовых библиотек компонентов, и он быстро изменяется (и как следствие глючит)
.net core в принципе будет работать с любым фронтом, но тогда тебе бэкенд вообще не нужен (всё из перечисленного — это уже комбинации бэк+фронт, т.е. два в одном)
Мне кажется удобно когда весь проект на одном язке (тайпскрипт конечно, про жаваскрипт можно забыть как о страшном сне)
Все из вышеперечисленного заточено на компиляцию и рендер (через жаваскрипт) на сервере.
Если тебе не нужет PageSpeed 100, то на это можно забить и делать по старинке.
Еще тут такой момент, какие ты планируешь использвать компоненты для UI?
Из готовых популярных бесплатных компонентов с открытым кодом (котороые в принципе нормальные, в т.ч. вставляются в вышеперечисленные фреймворки)
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, peer, Вы писали:
bnk>.net core в принципе будет работать с любым фронтом, но тогда тебе бэкенд вообще не нужен (всё из перечисленного — это уже комбинации бэк+фронт, т.е. два в одном) bnk>Мне кажется удобно когда весь проект на одном язке (тайпскрипт конечно, про жаваскрипт можно забыть как о страшном сне) bnk>Все из вышеперечисленного заточено на компиляцию и рендер (через жаваскрипт) на сервере. bnk>Если тебе не нужет PageSpeed 100, то на это можно забить и делать по старинке.
то есть постепенно .net core будет уступать долю в качестве бэка для сайтов для не сложных проектов?
а эти новые фреймворки я так понял кроме своей скорости хороши тем что не требуют мутных непонятных тонны пакетов как в реакте?
и еще вопрос эти новые фреймворки требуют чего-то на сервере кроме nodejs? типа работют только на nginx и т.п.
а то у меня винда серверная и иис по дефолту
bnk>Еще тут такой момент, какие ты планируешь использвать компоненты для UI? bnk>Из готовых популярных бесплатных компонентов с открытым кодом (котороые в принципе нормальные, в т.ч. вставляются в вышеперечисленные фреймворки)
Здравствуйте, peer, Вы писали:
P>то есть постепенно .net core будет уступать долю в качестве бэка для сайтов для не сложных проектов?
По мне так это давно уже так. В чем смысл делать несложный сайт на .net core?
P>а эти новые фреймворки я так понял кроме своей скорости хороши тем что не требуют мутных непонятных тонны пакетов как в реакте?
Папка node_modules при хостинге на nodejs все равно нужна.
Ну или сайт должен быть полностью статический (т.е. когда сервер вообще не нужен)
P>и еще вопрос эти новые фреймворки требуют чего-то на сервере кроме nodejs? типа работют только на nginx и т.п.
nodejs достаточно. Но обычно популярные хостиги тебе уже все предоставляют для nodejs приложений, ничего настраивать не нужно.
Просто указываешь на репозиторий в котором у тебя код, все остальное делает за тебя хостинг. Microsoft, Amamzon, Vercel, etc.
P>а то у меня винда серверная и иис по дефолту
Хм. Ты сам планируешь это хостить что ли (для пользователей), на домашнем сервере?
Если ты имеешь в виду для разработки, то IIS не нужен, nodejs все хостит само.
bnk>>Еще тут такой момент, какие ты планируешь использвать компоненты для UI? bnk>>Из готовых популярных бесплатных компонентов с открытым кодом (котороые в принципе нормальные, в т.ч. вставляются в вышеперечисленные фреймворки)
P>а я думал эти фреймворки они уже с компонентами. компоненты это какие на вид и возможностям компоненты?
Не, эти фреймворки чисто фреймворки. UI фреймворки без, собственно, UI, лол.
В смысле, визуальная часть, стили, контролы — это все отдельно (в сами фреймворки оно не входит)
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, peer, Вы писали:
P>>то есть постепенно .net core будет уступать долю в качестве бэка для сайтов для не сложных проектов?
bnk>По мне так это давно уже так. В чем смысл делать несложный сайт на .net core?
так то да, просто новый язык команда не знает и если даже ты решил и переписал, то потом в отпуск ушел надо чтобы кто-то поддерживал сайт твой
P>>а эти новые фреймворки я так понял кроме своей скорости хороши тем что не требуют мутных непонятных тонны пакетов как в реакте?
bnk>Папка node_modules при хостинге на nodejs все равно нужна.
а как у вас настроен процесс чтобы в гит не тащить сотни мегабайт этих пакетов, но при этом при деплоее на проде пакеты были?
P>>а то у меня винда серверная и иис по дефолту
bnk>Хм. Ты сам планируешь это хостить что ли (для пользователей), на домашнем сервере?
да, у нас внутренний апп и будет на нашем сервере крутиться. он в iis нормально работает из коробки?
Здравствуйте, peer, Вы писали:
P>>>а эти новые фреймворки я так понял кроме своей скорости хороши тем что не требуют мутных непонятных тонны пакетов как в реакте?
bnk>>Папка node_modules при хостинге на nodejs все равно нужна.
P>а как у вас настроен процесс чтобы в гит не тащить сотни мегабайт этих пакетов, но при этом при деплоее на проде пакеты были?
Сборка приложения и деплой производятся на билд-сервере скриптом.
Т.е. билд-сервер должен взять исходники из git, все сбилдить и задеплоить (в т.ч. сделать npm install)
Попсовые системы (github, microsoft devops, atlassian, vercel, aws) умеют сделать такой скрипт глядя на твой проект (показываешь ему на репозиторий и оно все делает само)
Я использую GitHub и DevOps для разных проектов. Но хостинг на (линуксовом) сервере (в облаке)
bnk>>Хм. Ты сам планируешь это хостить что ли (для пользователей), на домашнем сервере?
P>да, у нас внутренний апп и будет на нашем сервере крутиться. он в iis нормально работает из коробки?
В целом IIS не нужен, nodejs это уже сервер по сути (обычно для хостинга используется в виде PM2, чтобы работал в фоне и перезапускался если грохнется)
Для IIS в принципе есть модуль, но на него похоже давно подзабили: https://github.com/Azure/iisnode
P>>да, у нас внутренний апп и будет на нашем сервере крутиться. он в iis нормально работает из коробки?
bnk>В целом IIS не нужен, nodejs это уже сервер по сути
а там конфликта не будет с иис за 80 порт? на этом сервере на иис крутится другое еще
P>>>да, у нас внутренний апп и будет на нашем сервере крутиться. он в iis нормально работает из коробки? bnk>>В целом IIS не нужен, nodejs это уже сервер по сути P>а там конфликта не будет с иис за 80 порт? на этом сервере на иис крутится другое еще
Зря вы выставляете в паблик голый IIS. IIS уже устарел, да и порт 80 тоже. Но если так хочется, и нет желания перейти хотя бы 443, то можно другой ip использовать или reverse proxy сконфигурировать.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, peer, Вы писали:
P>>>>да, у нас внутренний апп и будет на нашем сервере крутиться. он в iis нормально работает из коробки? bnk>>>В целом IIS не нужен, nodejs это уже сервер по сути P>>а там конфликта не будет с иис за 80 порт? на этом сервере на иис крутится другое еще ·>Зря вы выставляете в паблик голый IIS. IIS уже устарел, да и порт 80 тоже. Но если так хочется, и нет желания перейти хотя бы 443, то можно другой ip использовать или reverse proxy сконфигурировать.
а, так то у нас будет 443 конечно. Просто из старой памяти вспомнил конфликты с апач у иис.
А чем иис устарел и что вместо него сейчас используется для корпоративного внутреннего софта?
кстати, 100 лет не занимался доменами и сертификатами. у нас этот сайт будет внутри глобального сайта компании типа
1. это надо будет в глобальном сайте в днс таблицах прописать айпи нашего для данного урла?
2. сертификат надо использовать отдельный для нашего подсайта?
Здравствуйте, peer, Вы писали:
P>·>Зря вы выставляете в паблик голый IIS. IIS уже устарел, да и порт 80 тоже. Но если так хочется, и нет желания перейти хотя бы 443, то можно другой ip использовать или reverse proxy сконфигурировать. P>а, так то у нас будет 443 конечно. Просто из старой памяти вспомнил конфликты с апач у иис.
Обычно один web server ставится как фронт — для сертов, балансировки, high-availability и прочего, и ещё один (или много) как бэк — для собственно приложух(и). Т.е. :443 реверс-проксируется на какой-нибудь условный :12345, возможно даже на другом хосте(хостах).
P>А чем иис устарел и что вместо него сейчас используется для корпоративного внутреннего софта?
контейнеры же.
P>кстати, 100 лет не занимался доменами и сертификатами. у нас этот сайт будет внутри глобального сайта компании типа P>https://www.myCompany/ourSite P>1. это надо будет в глобальном сайте в днс таблицах прописать айпи нашего для данного урла?
Ну, во-первых, "www." тоже устарел. Во-вторых, айпи прописывается не для урла, а для имени домена. Т.е. используйте просто https://oursite.mycompany.com/
P>2. сертификат надо использовать отдельный для нашего подсайта?
Сертификат тоже для доменного имени.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, peer, Вы писали:
P>>·>Зря вы выставляете в паблик голый IIS. IIS уже устарел, да и порт 80 тоже. Но если так хочется, и нет желания перейти хотя бы 443, то можно другой ip использовать или reverse proxy сконфигурировать. P>>а, так то у нас будет 443 конечно. Просто из старой памяти вспомнил конфликты с апач у иис. ·>Обычно один web server ставится как фронт — для сертов, балансировки, high-availability и прочего, и ещё один (или много) как бэк — для собственно приложух(и). Т.е. :443 реверс-проксируется на какой-нибудь условный :12345, возможно даже на другом хосте(хостах).
то есть сначала идет запрос на первый веб, где серты, балансировка и потом уже оттуда идет запрос на 443 на веб2, где приложения и на порту 12345 лежит контейнер с нужным приложением
P>>А чем иис устарел и что вместо него сейчас используется для корпоративного внутреннего софта? ·>контейнеры же.
а если по первому пункту правильно понял, то как контейнер с приложением которые висят на 12345 видны веб серверу? современные веб-сервера из коробки видят контейнеры?
я кстати тут недавно со знакомым говорил и говорит вроде мода кубернец прошла и типа он плохо умеет ресурсами управлять, как скл сервер захватил и не отпускает. Детали не спрашивал прям.
Здравствуйте, peer, Вы писали:
P>>>а, так то у нас будет 443 конечно. Просто из старой памяти вспомнил конфликты с апач у иис. P>·>Обычно один web server ставится как фронт — для сертов, балансировки, high-availability и прочего, и ещё один (или много) как бэк — для собственно приложух(и). Т.е. :443 реверс-проксируется на какой-нибудь условный :12345, возможно даже на другом хосте(хостах). P>то есть сначала идет запрос на первый веб, где серты, балансировка и потом уже оттуда идет запрос на 443 на веб2, где приложения и на порту 12345 лежит контейнер с нужным приложением
Браузер идёт на первый веб (nginx, haproxy, traefic, etc), порт 443 домена mysite.mycompany.com, там серты/балансировка/роутинг. Потом идёт на какой-нибудь внутренний ip:12345 — уже сами приложухи-сервисы — iis, nodejs, tomcat/jetty, etc.
P>>>А чем иис устарел и что вместо него сейчас используется для корпоративного внутреннего софта? P>·>контейнеры же. P>а если по первому пункту правильно понял, то как контейнер с приложением которые висят на 12345 видны веб серверу? современные веб-сервера из коробки видят контейнеры?
Что значит "видят контейнеры"? Контейнер это обычный ip+port с т.з. фронт-веба.
P>я кстати тут недавно со знакомым говорил и говорит вроде мода кубернец прошла
Это как? Куда прошла? Докеру появились альтернативы типа podman. Для облаков появились и готовые 3rd party типа amazon ecs. И т.п.
P>и типа он плохо умеет ресурсами управлять, как скл сервер захватил и не отпускает. Детали не спрашивал прям.
Фигня какая-то.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, peer, Вы писали:
P>>>да, у нас внутренний апп и будет на нашем сервере крутиться. он в iis нормально работает из коробки?
bnk>>В целом IIS не нужен, nodejs это уже сервер по сути
P>а там конфликта не будет с иис за 80 порт? на этом сервере на иис крутится другое еще
Будет. Поэтому и речь про модуль (iisnode). Если хостить на IIS я бы попробовал его сначала.
Ну или прокси как выше . написал (перенаправление с фронта на отдельный контейнер или компьютер)
Для IIS можно легко сделать через модуль URL Rewrite и web.config
Но вообще для внутреннего использования (если это не публичный сайт, а внутри компании, куда заходит десять человек в день),
почему бы и вправду не сделать просто SPA (статический сайт?). Никаких вопросов с хостингом не будет.
Кстати, тебе бэкэнд вообще нужен? База например какая-нибудь? Аутентификацию какую-то предполагается использовать?
Если "встроенную в Windows" (доменную в смысле, не удивлюсь если у вас IIS) то у NODE с этим легко будут проблемы,
особенно в сценарии если под юзерским "виндовым" аккаунтом пытаться лезть в базу например или к другому веб-сервису в сети вашей организации
(в смысле, делегация/керберос на ноде не взлетит)
В общем есть нюансы
Я имел в виду скоее сценарий публичного сайта, который хостится в облаке,
и куда заходит толпа народу, причем если он грузится больше секунды,
то это уже все капец, закроют и уйдут.
Для локального сайта в организации, завязанной на Microsoft — почему бы не шарепоинт например?
Вообще ничего особо писать не надо. Сейчас там конструктор страниц стал вполне вменяемым IMHO.
Примерно те же блоки что и везде. Свои тоже можно добавлять при необходимости.
Здравствуйте, peer, Вы писали:
P>Идут годы, а я не делал Single page аппы для веба. На горизонте веб-проект и поэтому хочу понять текущую ситуацию, когда лучше Single page а когда обычное веб приложение с перезагрузкой
По умолчанию — SPA.
Когда я бы советовал делать обычное:
— Если исполнитель не знает JS/TS (ну или принципиально не хочет этого касаться, такое бывает), но сайт делать надо.
— Если делается публичный информационный сайт, который должен индексироваться поисковиками и другими сервисами. Тут, конечно, не обязательно всё делать без JS, лишь основной функционал. К примеру новостной сайт делаем работающим без JS, а добавление комментариев через JS. Наверное это уже нельзя называть SPA. Добавлю, что сейчас модно делать гибридные сайты, которые работают и без JS, и с JS.
— Если у клиента по каким-то причинам проблемы с выполнением JS. Честно говоря сложно представить такую ситуацию, но мало ли. Может целевая аудитория — гики-хейтеры JS.
— Если исполнитель очень хорош в создании обычных веб-приложений. Занимался этим последние 20 лет, клепает страницы одна за одной. SPA может и готов делать, но явно будет делать это значительно дольше.
