B
тогда зайду с другого конца
Size: a a a
2020 October 19
DC
если фронт сгенерен в статику и лежит там же, где и бэк (например в resources/static у спринга), то разницы по идее не будет. А если фронт отдельный, как нередко делается? Тогда запрос пойдет не напрямую в бэк, а сначала на нодовский сервер, который запрос разберет, потом отправит запрос на твой бэк и далее по списку. Лишние шаги взаимодействия
Очень мало кто в здравом уме и трезвой памяти будет использовать прокси на ноде, не неси чепухи, пожалуйста.
Запрос к серверу что с JSF, что с отдельным фронтом на каком-нибудь там реакте, генерится на клиенте силами JS-кода, обработка ответа от сервера происходит им же, опять же, что с JSF, что с каким-то реактом. Просто JSF от тебя это прячет.
Запрос к серверу что с JSF, что с отдельным фронтом на каком-нибудь там реакте, генерится на клиенте силами JS-кода, обработка ответа от сервера происходит им же, опять же, что с JSF, что с каким-то реактом. Просто JSF от тебя это прячет.
B
как я представляю себе работу фронта: либо он рендерит все на клиенте (отправляя туда бандл всякого разного, вполне мб, что и всяких рантаймов фреймворка), либо на сервере (формируя html+css+js странички и отправляя), либо сразу генерит статику (html + css + js). Вот если первые два варианта, кто посылает бандл, кто генерит страничку?
ch
как я представляю себе работу фронта: либо он рендерит все на клиенте (отправляя туда бандл всякого разного, вполне мб, что и всяких рантаймов фреймворка), либо на сервере (формируя html+css+js странички и отправляя), либо сразу генерит статику (html + css + js). Вот если первые два варианта, кто посылает бандл, кто генерит страничку?
вы хотя бы описание протокола HTTP читали или сейчас просто с головы сыплете?
ch
GET POST там?
B
причем клиентский рендеринг не приветствуется, потому что страничка с ним не индексируется поисковиками + клиенту надо ждать, пока оно там отрисуется
B
вы хотя бы описание протокола HTTP читали или сейчас просто с головы сыплете?
это модно нынче, отвечать вопросом на вопрос?
я как-то привык, что если человек заблуждается, то ему объясняют, в чем он не прав и как на самом деле все. И желательно с аргументами
я как-то привык, что если человек заблуждается, то ему объясняют, в чем он не прав и как на самом деле все. И желательно с аргументами
ch
если вы без понятия что такое HTTP то весь разговор от самого начала до вероятного конца не имеет обсолютно НИКАКОГО смысла
B
вы сделали утверждение, что я без понятия о get/post запросах, вместо какой-то аргументации. Вместо объяснения, что конкретно вас не устроило и тд
B
т.е. как я представляю адекватную критику: "ты не прав, потому что вот это и это работает не так, а вот так". И никак не "лол, да ты ничо не знаешь)"
ch
ch
для начала хватит
А
причем клиентский рендеринг не приветствуется, потому что страничка с ним не индексируется поисковиками + клиенту надо ждать, пока оно там отрисуется
Сейчас все отлично индексируется и в случае с клиентским рендеренгом. Но это даже не важно. Можно фронт положить отдельно, можно в ресурсы спринга, можно срендерить самим спрингом. Но везде все будет одинаково взаимодействовать с сервером. Так, как будет заложено в архитектуру.
ch
как вы html собрались рендерить на сервере? а если нет то почему для вас рендеринг js означает что теперь у нас на клиенте уже ничего рендерить не нужно
А
как вы html собрались рендерить на сервере? а если нет то почему для вас рендеринг js означает что теперь у нас на клиенте уже ничего рендерить не нужно
эм... Ну если ко мне, то под рендеренгом я подразумевал формирование готового html-кода)
В
сейчас в 90% случаев идет отдельный фронт. И он даже не обязан быть на том же сервере. На бэке делается апи (рест, например), фронт стучится на этот апи и получает в ответ жсоны. Так работают и реакт, и ангулар, и вью. Без этого можно разве что jsf использовать или thymeleaf с аналогами, но их очень мало (во что кстати с трудом верится после просмотра, например, клиентов PrimeFaces PRO)
я так и подумал - спасибо )))!
B
Алексей
Сейчас все отлично индексируется и в случае с клиентским рендеренгом. Но это даже не важно. Можно фронт положить отдельно, можно в ресурсы спринга, можно срендерить самим спрингом. Но везде все будет одинаково взаимодействовать с сервером. Так, как будет заложено в архитектуру.
ну про индексацию - по крайней мере в чатах по ангулару и наксту в один голос говорили, что без ssr не будет нормального seo (и это вынесено в основные плюсы того же накста на их сайте)
B
спасибо, почитаю
А
ну про индексацию - по крайней мере в чатах по ангулару и наксту в один голос говорили, что без ssr не будет нормального seo (и это вынесено в основные плюсы того же накста на их сайте)
это старая инфа. Да, гугл и яндекс накладывают определенные ограничения на клиентский рендеринг, но они так же его индексируют