Какой дурак использует фреймворки?

Ну да. Просто в случае с SSR это может сделать за вас ваш бэкенд, и лично вам этот токен иметь будет не обязательно.

Иметь - обязательно. Иначе откуда backend и SSR поймут, что они имеют право выдавать конкретные приватные данные наружу?

да нет, у него просто шизофрения, я часто такое замечаю. чем старше разработчик тем больше он начинает придумывать дичи. и никто же его не остановил, за рукав не отдернул, потому что старший, а значит автоматом шарит.

Гонять хром в кубере чтобы поисковику зарендерить html, это верх идиотизма. Если бы я такое на созвоне выдал, меня бы мой тимлид через камеру тапком отпздл. И был бы прав!

идёт в ногу со временем и с современными технологиями

Прям как родители которые узнали что такое мемесы, и пытаются с тобой ими разговаривать 💀 How do you do, fellow kids?

Иметь - обязательно. Иначе откуда backend и SSR поймут

К примеру, бэкенд выдаёт вам сессионную куку после аутентификации. Когда вы запрашиваете у него страницу с лентой рекомендаций, он смотрит, кто вы такой, и если партия одобряет, идёт в сервис рекомендаций с вашим идентификатором и своим токеном, получает жсон, рендерит HTML для ленты рекомендаций и отдаёт вам.

Вуаля, у вас нет токена от сервиса рекомендаций, но есть ваша лента.

Загляните в prerender.io и поинтересуйтесь, как это работает - если конечно ваших младенческих мозгов хватит, чтобы разобраться :)

Гонять хром в кубере чтобы поисковику зарендерить html, это верх идиотизма

Тут свои плюсы есть — клиентское и серверное окружения (более-менее) идентичны (и там, и там браузер), так что разработчику теоретически меньше мороки. Не надо думать, что будет выполняться на ноде, а что в браузере — всё будет выполняться в браузере.

Конечно, когда в качестве довода в пользу такого решения приводят экономию ресурсов (которые тупые фронтомакаки непременно растранжирят, если им дать писать кот для бэкенда), есть небольшое желание хрюкнуть %)

… и если партия одобряет, идёт в сервис рекомендаций с вашим идентификатором и своим токеном, получает жсон

В моей терминологии «токен» - это и есть ваша «кука») «Токен», в вашем понимании (или, к примеру юзер-пароль к БД), никогда на клиент не попадает - это чисто внутренняя кухня сервера.

«токен» - это и есть ваша «кука»

Это всё-таки малость разные вещи, хотя бы чисто технически. К примеру, http-only куку сторонний скрипт стащить не сможет, а токен из localStorage — запросто.

Вы давно проводили аудит кода для всех своих браузерных расширений? %)

К примеру, http-only куку сторонний скрипт стащить не сможет, а токен из localStorage — запросто.

ну тут уж решать фронту, что безопаснее использовать. Если выбрали «куку», то токен и не требуется в любом случае

Если выбрали «куку», то токен и не требуется в любом случае

А если сервис рекомендаций сторонний и куки ваши принимать не хочет ни в какую, токен какой-то требует?

А если сервис рекомендаций сторонний и куки ваши принимать не хочет ни в какую, токен какой-то требует?

ну тогда правильнее выдавать такие запросы через сервер своего приложения предоставляя ему только свою куку и предварительно сохранив там токен в своем профиле - опять же чисто на уровне серверной логики

Ну, допустим, «токен = логин/пароль в БД = SSL ключи = ещё_как_ни_назови» - это уже дело бэка куда он там пойдёт и как его там будут просить представится.

В вашем примере, с предположительно сторонним сервисом рекомендаций, больше смущает, что рекомендации-то на то рекомендации, что должны быть индивидуальны. Т.е. вот пришло к вам 40 000 уникальных рыл - и вы 40К раз единомоментно дёргаете стороннее API? И работает? И API успевает каждого посчитать, и по сети каждого перегнать?

пришло к вам 40 000 уникальных рыл - и вы 40К раз единомоментно дёргаете стороннее API?

Мы тут вроде не за архитектуру сервисов балакаем, а за SSR и его преимущества в плане безопасности всего-то навсего %)

тогда правильнее выдавать такие запросы через сервер своего приложения предоставляя ему только свою куку

SSR через PHP, короче говоря. И чем это принципиально отличается от SSR через ноду? Тем, что для этого нужен отдельный проект и отдельный пхпшник для его поддержки?

базы данных на фокспро, которая на досе

Разве её нельзя 1:1 перетащить в Firebird, который бывший Interbase? И почему он этого не сделал?

Во всяких 1Ц и подобных ... Виртуальность виртуальностью погоняет.

Для системы, завязанной на «проводки», это нормально. Всё-таки sql предполагает DELETE и TRUNCATE.

SSR через PHP, короче говоря. И чем это принципиально отличается от SSR через ноду?

Ну backend-API, как следующий слой, у вас в любом случае есть - SSR его не отменяет. И предоставлять данные для формирование HTML - это дело backend-а. SSR, вообще говоря, предназначен вовсе не для такой «оптимизации».

успешнее втюхивать

ещё скажи, что это заговор фанатов турбопаскаля/C#

А. Пардон. Думал у вас это из реальной жизни пример. Больной вопрос. Уж думал выпытывать у вас подробности архитектуры.

а разметка отдельно, активности отдельно и т.д и т.п,

Вот только веб-разметка в UI - это какой-то рак и изврат. Это как UI в ворде на листе делать.

sql предполагает DELETE

не делают в реальных продуктовых базах физический DELETE.

Я вообще не понял, зачем SSR нужен для какого-нибудь бэкэнда с развесистым шаблонизатором: гораздо проще и быстрее скормить объект той же jinja2 с накиданным в pug шаблоном, чем тюнить SSR ангуляр, шоб он нормально рисовался.

Больной вопрос. Уж думал выпытывать …

А в чем проблема? Платите денежку владельцам стороннего API, чтобы обслуживали все запросы. Поднимаете, к примеру, кластер в облачной платформе, и платите денежку владельцу облачной платформы, чтобы он обеспечивал надежную поддержку соответствующего количества параллельных запросов к внешнему ресурсу…

Всё равно это несколько иное, чем сторнирование.

когда в качестве довода в пользу такого решения приводят экономию ресурсов (которые тупые фронтомакаки непременно растранжирят, если им дать писать кот для бэкенда)

Код изоморфного фронтенда один и тот же что для клиента, что для сервера, а бекенд (доступный через HTTP API) будут писать совсем другие люди.

Вот только веб-разметка

Чем она принципиально отличается от xml в андроиде или от декларативного описания?

Принципиально - ничем. А в деталях настолько убога, что без Bootstrap + SASS ничего по-людски не сделать. Любая формошлёпка в стиле дельфи даёт более приемлемый результат.

Честно говоря у нас даже локально БД+бэк на одном физическом хосте с аккуратно поделенными между ними ресурсами хоста еле вывозят. Если у тебя 40 000 одномоментных уников и каждому (какой-то умный руководитель придумал) выдавать 300КБ объема в рекомендациях - это тебе надо иметь в районе 96Гбс канал связи. Или я что-то не понимаю?

Bootstrap — это система сеток + базовый стиль оформления. Вместо системы сеток давно можно flex и grid использовать, а стилевое оформление чаще всего всё равно своё будет. SASS же, благодаря стандартным переменным, вложению, слоям и Shadow DOM уже почти не нужен.

Любая формошлёпка в стиле дельфи

…не умеет в адаптивность

в адаптивность

Нужно только для отображения аналогов бумажного формата на экране

а стилевое оформление чаще всего всё равно своё будет

Да блин нахрена это всё? Чтоб нормально выглядело, нужно сношаться с вёрсткой, фигмой, шрифтами, полями... Дайте мне нормальные гриды и рулеры как в tk/gtk/wx и общесистемно стилизованные контролы.

поинтересуюсь конечно, но не проще ли для SEO запилить простой лендинг и добавить субдомен для приложения? я вот своим младенческим мозгом не могу понять зачем так извращаться в принципе? изначальная задача в чем? что динамические веб приложения плохо подходят для поисковиков

это тебе надо иметь в районе 96Гбс канал связи. Или я что-то не понимаю?

Не совсем так) Если каждую секунду ломятся по 40000 абсолютно других уников, и их запросы надо обслуживать в течении секунды - то да, если вы правильно посчитали) А если у сервиса просто всего 40000 разных юзеров, то пропускная способность определяется минимально допустимой скоростью выполнения их запросов. Вроде так…

но не проще ли для SEO запилить простой лендинг и добавить субдомен для приложения?

SEO - это индексация в поисковиках всех страниц приложения (к примеру, всех страниц TikTok), а не только одной лендинг-страницы.

нормальные гриды и рулеры

так есть же

общесистемно стилизованные контролы

input и select из коробки системный стиль имеют

У них системный стиль даст прикурить Tk.

А что есть по рулерам в стиле gtk?

индексация в поисковиках всех страниц приложения

SEO means Search Engine Optimization and is the process used to optimize a website’s technical configuration, content relevance and link popularity so its pages can become easily findable, more relevant and popular towards user search queries, and as a consequence, search engines rank them better.

Нигде не сказано что нужно прям все страницы индексить

вообще для SEO не обязательно идексировать все страницы приложения. много от приложения зависит, если к примеру для социалки аля TikTok, Youtube, etc это еще понятно. Все таки видео или посты с платформы должны отображаться в поиске, а вот например индексить SaaS приложение не имеет смысл, а еще это опасно, потому что можно случайно пользовательские данные заиндексить и тогда GDPR придет тебе домой с огромной юридической елдой битой и сломает тебе колено 😱😱😱

Нигде не сказано что нужно прям все страницы индексить

Вы видимо студент - или, возможно, даже школьник. Поэтому пытаетесь «аргументировать» и «поучать» чисто абстрактно - на основе формальных определений, а не на основе реального опыта. Я же здесь говорю о вполне конкретных приложениях, где необходимо индексировать все существенные страницы.

По тем рулерам, которые из гтк удалили?

Прошу прощения, дислексия - сайзеры т.е., вот все эти «контейнеры» в glade и подобных.

Так обычные HTML-элементы с display: flex в качестве контейнеров, если я правильно понял, о чём речь

Так, но не так. В формошлёпках (либо просто кодом) оно не едет куда попала и не нуждается в «адаптивном дизайне».

Флекс никуда не едет, если ему не будет специально сказано. А адаптивный дизайн нужен для разной ширины мониторов.

ну тут уж решать фронту, что безопаснее использовать.

У вас 8 ошибок в слове бэкенд. Если безопасность у вас решает фронтенд, то у вас нет безопасности.

А причем тут delete и truncate?

У вас 8 ошибок в слове бэкенд. Если безопасность у вас решает фронтенд, то у вас нет безопасности.

Ох уж эти буквоеды…) «backend» - так безопаснее?))
Кто там чего решает, это напрямую к тому трёпу не имело никакого отношения. В принципе, если речь шла об использовании стороннего API-сервиса, то можно было хранить на своем сервере refresh-токен этого сервиса (если достаточно одного) и отдавать на свой frontend временный токен для выполнения API-запроса к внешнему сервису. Так тоже работают.

Ну, если достаточно быстро загрузить ~200к - это суровая проблема для соединения, то конечно) Но сейчас ведь везде WiFi.

Это ведь троллинг да? скажите что троллинг… а то у меня глаз дергается.

P.S. Рекомендую съездить в горы и внимательно следить за индикатором сотовой связи и считать количество палок там. И да искать там WiFi вдруг в каком горном ауле будет.

… Это ведь троллинг да? скажите что троллинг… а то у меня глаз дергается.

Ну вы не переживайте так сильно )) Просто перечитайте весь разговор. Я думаю, в горах ничего страшного не случится, если при первом заходе на сайт, когда в кеш реально будет грузиться весь js-код, вы подождете ровно столько, сколько сплошь и рядом грузятся обычные картинки) Я вон сейчас вообще на 64Кбит сижу - и ничего, не истерю))

… и пребывая в горах ни в коем случае не заходите посредством веб-обозревателя в youtube и прочие интересные места - иначе вас просто удар хватит!))

И да искать там WiFi вдруг в каком горном ауле будет.

Почему нет?