Разработка Web-интерфейса с пользователем.

Потому что есть 100500 клиентов, которым нужные данные, которые в БД.

Действительно:

Я не связываю вебсокет с БД. Я не понимаю, откуда ты это взял?
Мне не нужно открывать соединение к БД на соединение с WebSocket-сервером. Мне нужно отвечать на запросы данных от клиента, которые необходимо получать из БД. (Они там в структурированном виде лежат.)

Ты уж определись, связываешь или нет. Но я тебе сообщаю, что для ответа и получения данных для 100500 клиентов не нужны 100500 коннектов к базе.

Зачем ты врёшь, у тебя ведь явно пхп-мышление? Я то вижу, ведь это по сути одно единственное место, где можно так исказить своё восприятие.

Сел в лужу и пошел стучать? Какой молодец.

Ты уж определись, связываешь или нет.

Я связываю клиентов с БД, а не соединения.

Но я тебе сообщаю, что для ответа и получения данных для 100500 клиентов не нужны 100500 коннектов к базе.

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

Тащемта, это Царь. Не узнали что ли до сих пор.

Ну это уже проблемы кодера, что он выбирает себе неподходящий инструмент. Сейчас на любую фигню есть сотни аналогов.

Не работают эти аналоги, я же примеры привел с нескольких ракурсов осмысления. Не проецируй проблемы инструментов на проблемы кодера.

Тащемта, это Царь. Не узнали что ли до сих пор.

Ой, его вынесли. Я уже и ответ ему написал, а он исчез. Лол.

Нет, это именно проблемы кодера, если он подключает зависимости ради < 50% функционала из них.

См. http://программирование-по-русски.рф/как-сделан-этот-сайт.яргт - там про недостатки vue. Не знаю, насколько оно неразрешимое. Решение есть всегда: забить на качество и безопасность данных пользователей. Не будем забывать, что вся силиконая долина мыслит сегодня в терминах бункеров в Новой Зеландии, и частных самолётов, которые позволят до этих бункеров долететь. А данные пользователей уже оптом продаёт фейсбук. Поэтому на какие-то мелкие недостатки можно не обращать внимания. Бросай лодку в очередную мутную реку, ставь весло и жди, пока наплещет золотых рыбок.

Второй вариант - я просто недостаточно опытный веб-разработчик (и месяца этим не занимался), и просто не додумался до нормального решения.

Не подскажешь, как в этом случае страницу боту отдавать?

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

См. http://программирование-по-русски.рф/как-сделан-этот-сайт.яргт - там про недостатки vue

Суть проблемы сводится к семантике SSR (на сервер не попадает клиентский токен безопасности)

Ничего не понял. В чём проблема передать клиентский токен через Ajax или WebSockets?

Где пруфы, местный балаболка, что я сел в лужу? От тебя ни одного аргумента, ни одного факта, один каломёт :-)

Где пруфы, местный балаболка, что я сел в лужу? От тебя ни одного аргумента, ни одного факта, один каломёт :-)

Пруфов не будет. Максимум - фантазии пубертатного периода. Это проходит, ничего страшного.

Не подскажешь, как в этом случае страницу боту отдавать?

В случае динамического формирования существенного содержимого страницы на стороне веб-обозревателя - смотри «Google: AJAX Crawling». Конкретно, следует задействовать методу, указанную в разделе «Pages without hash fragments», т.е. использование метатега:

<meta name="fragment" content="!">

На текущий момент, это, пожалуй, единственный практичный вариант, если не хочется иметь проблем с SEO.

Что касается формирования HTML-снапшотов, то можно самому написать на базе PhantomJS (или другого headless-обозревателя с возможностью извлечения HTML из DOM) - увеличивает требования к оперативной памяти сервера, ну и время формирования снапшота тоже нужно принимать во внимание. Если самому не хочется с этим заморачиваться, то есть соответствующие online-сервисы, типа PRERENDER.IO.

Как-то так...

Нельзя передать клиентский токен через Ajax, т.к. он не должен быть доступен в JS. Насколько я понял (там есть ссылка на обсуждение безопасного способа, httponly cookie). Но опять же - мой опыт в вебе слишком мал. Если я пишу глупость, то буду рад, если меня поправят.

какому боту? яндексу? можно в скрытом диве все текстом пихать, можно для ботов сделать отдельные вьюхи, можно заблочить их к чертям собачьим, потому что ненeжно

Да уж... ))) Это как раз в тему о «не самых приятных сюрпризах», с которыми потом столкнется владелец сайта, подрядивший такого такого веб-разработчика.

Нельзя передать клиентский токен через Ajax, т.к. он не должен быть доступен в JS.

Как это он не должен быть доступен в JS? А как же тогда вообще возможно организовать аутентификацию? На клиентской стороне по-любому должен быть некий идентификатор, зная который, можно попросить сервер выполнить некое действие, требующее авторизации. По-другому никак.

какой правильный вариант ответа?

какой правильный вариант ответа?

Правильный вариант ответа читай выше.

Что касается «можно в скрытом диве все текстом пихать» и «можно заблочить их к чертям собачьим, потому что ненeжно» - это говорит о том, что вы (как и многие другие веб-программисты) не имеют особого представления о SEO. А надо бы... За скрытые дивы, в частности, сайт могут очень сильно наказать.

"... потому что ненeжно" => "... потому что ненужно"
Извиняюсь за опечатку )

Ссылку прочитал?

Ссылку прочитал?

Да.

Ну тогда > 50% жеесников — проблемные. Нет, давай так: > 50% авторов либ — проблемные, понапишут понапихают хрен пойми чего.

В меру моего ограниченного понимания, http-only cookie - это кука, которую нельзя получить в коде js. Соответственно, её нельзя запихнуть в json, нельзя составить из неё URL. Единственное, что с ней происходит - это она отправляется обратно серверу и доступна серверному обработчику http запроса в соответствующем поле.

Если токен доступен в коде JS, то вредоносный код легко может его похитить.

Поэтому, любая техника, которая работает с аутентификационной инфой в js - небезопасна. Опять же, это в меру моего понимания, буду рад ошибаться - тогда, глядишь, и окажется vue пригодным к использованию.

Ссылку надо читать вот эту: https://habr.com/post/143259/

В меру моего ограниченного понимания, http-only cookie - это кука, которую нельзя получить в коде js. Соответственно, её нельзя запихнуть в json, нельзя составить из неё URL. Единственное, что с ней происходит - это она отправляется обратно серверу и доступна серверному обработчику http запроса в соответствующем поле.

HttpOnly - это просто дополнительное свойство куки, которое теоретически делает куку недоступной для ширпотребных браузеров из JS. Это верно.

Если токен доступен в коде JS, то вредоносный код легко может его похитить.

Для этого надо успешно осуществить XSS-атаку и внедрить вредоносный код на сервер. Либо воспользоваться отсутствием какой-нибудь фильтрации ввода, что тоже характеризует создателя сервиса как лопуха. Если сервис сделан с учётом XSS/CSRF, то провернуть финт с похищением данных из браузера очень не легко. Для этого нужно воспользоваться уже дырой в браузере. Но дыры бывают разными, в т.ч., нет гарантий отсутствия дыр, с помощью которой можно получить и куку, помеченную как HttpOnly.

Поэтому, любая техника, которая работает с аутентификационной инфой в js - небезопасна.

Ну так в мире нет ничего безопасного. Безопасность абсолютной не бывает.

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

sessionData.sharedCookie = hash(sessionCookie + browserFingerPrint);
if (requestSharedCookie != sessionData.sharedCookie) {
    // сброс и отлуп
}
setHeader(sessionCookie);
setHeader(sessionData.sharedCookie);

Можешь на стороне бекенда навесить на формирование хеша фингерпринты браузера

Из чего предлагаешь получать фингерпринт браузера?

Как минимум телодвижений: сразу из заголовков запроса. Как экстра: сбор инфы клиента прямо перед запросом.

Поглядел комментарии к этому посту - там много полемики. И не стоит забывать, что это 2012 год. Т.е. пост мог устареть. Тогда можно опуститься вниз по стеку и проблема будет так выглядеть:

Суть проблемы сводится к семантике SSR (на сервер не попадает клиентский токен безопасности) и к тому, что после обновления страницы состояние приложения, хранящееся в переменных JS, теряется

Соответственно, аутентифицированные страницы нельзя сгенерировать на сервере - мне это не нравится. Хотя, возможно, это моя личная проблема и я хотел применить вуй не так, как он задуман. А вот проблема с нажатием F5 и потерей состояния страницы, хранящегося на клиенте, мне совсем не понравилась. Я не нашёл её решения.

Я это решение только что предложил. При обновлении страницы всегда считать что запрос идет не на апи, а значит шаред куку можно не сверять, т.к. хттп онли кука не может быть стырена злым жс скриптом из СПА.

Может быть, это и решение (я пока мало что понял, да и вообще я сейчас не в контексте веба, а меня позвали), но оно должно быть в контексте vue.js, чтобы этим пользоваться. Может быть, есть магия, как его туда встроить, а может быть, и нет. Если просто так брать примеры на vue.js, то они страдают кривизной при обновлении страницы, и сообщество на момент моих изысканий не имело внятного ответа (который я смог бы найти).

И напоминаю (меня тут уже один раз потёрли), что официальный форум vue.js в значительной части на китайском языке.

Соответственно, аутентифицированные страницы нельзя сгенерировать на сервере - мне это не нравится.

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

А вот проблема с нажатием F5 и потерей состояния страницы, хранящегося на клиенте, мне совсем не понравилась. Я не нашёл её решения.

Пожалуйста - Веб Хранилище - Web_Storage_API.

И напоминаю (меня тут уже один раз потёрли), что официальный форум vue.js в значительной части на китайском языке.

Что насчёт Vue. Есть какой-нибудь в нём смысл, если я знаю JavaScript, знаю DOM, знаю HTTP? Я ознакомился за пару дней с Vue и React. Впечатления как от каких-то клеток, которые ограничивают в действиях. Так же впечатления похожие на «ешь то, что дают, это вкусно, верь нам».

Vue обещает более-менее лёгкую (без программирования) поддержку SPA, SSR, возможность разбивать на повторно используемые компоненты, сериализацию html в виде JS, привязку данных к компонентам страниц, которая со всем этим согласована. На мой взгляд, там всё кривовато и плохо документировано, но см. выше мои стандартные отречения. Насчёт «верь нам» - да, сейчас полно хайпа. Вкусна зарплата, которую выделяют те, кто каким-то образом поучаствовал в продвижении этого хайпа перед своим источником денег. Вот и вся вкуснота. О полезности таких решений я вести речь не могу. Вот, например, был хайп про SPA, но такую элементарную вещь, как работу с поисковиками, забыли. Т.е. возник конкретный разрыв, когда такие приложения внедрили и вдруг обнаружили эту проблему. В таком контексте видимо, речь о проектировании особо не шла, а значит, доверять таким фреймворкам не стоит. Но см. моё стандартное отречение - я не спец по вебу, а полный чайник.

Насчёт эффективности моей работы - я неоднократно сталкивался с ситуацией, что конфиг никак не валидируется и простая опечатка приводит к молча не работающему приложению. Мне не нравится. Не на то мы живём в XXI веке, чтобы глазами опечатки искать. Для этого есть наши кремниево-алюминиево-золотые друзья компьютеры.

Но это я так понял, совершенно общая проблема в вебе.

Опять же, веб-хранилище - это круто, но его нужно ещё прикрутить к vue. И желательно, чтобы это не было багой, которая обнаруживается и которую никто не может починить, а чтобы автор vue изначально об этом подумал. И опять же, если страница генерируется на сервере, то эта инфа туда как попадёт?

Опять же, веб-хранилище - это круто, но его нужно ещё прикрутить к vue.

Vue - это всего лишь методика описания примитивных интерфейсов (аля формошлёпство), задействуя хиповую методику «двунаправленного связывания», с помощью специального DSL, из которого потом с помощью некоего транслятора генерится JS-код. Всё. На этом Vue заканчивается, как мне показалось.

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

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

Ну я поэтому и считаю, что в современном DOM API есть всё, что нужно для нормальной работы. Vue - это для озабоченных делать по 100500 проектов в год. По мне это смахивает на зависимость. Мне не понятно, зачем люди стремятся сделать по 100500 проектов в год? Что они от этого приобретают? Сидеть целыми днями и ночами и клепать однотипные сайты на Vue/React/Angular - тыщи их - это что, такой великий кайф? Миссия? Я не знаю, в общем, зачем многие кричат про бойлерплейт, видимо у них по десятку однотипных проектов, и они от этого счастливы. Лол.

И опять же, если страница генерируется на сервере, то эта инфа туда как попадёт?

Эта инфа попадёт в браузер.

Vue - это всего лишь методика описания примитивных интерфейсов

Man nuxt.js и иже. Я у себя на «программирование-по-русски» описал некоторые компоненты семейства vue, в которое входит далеко не только собственно vue.

Vue - это для озабоченных делать по 100500 проектов в год.

Меня оно привлекло не столько хайпом, сколько обещанием возможности бить код на управляемые компоненты. Так, что html, css и js для каждого компонента описывается в одном файле. Т.е., всё, что относится к данному компоненту, собрано вместе, а дальше его подключаешь к описанию страницы. А не то, что нужно сделать руками какие-то действия в нескольких местах - это подвержено ошибкам и потом сложно понять структуру страницы, по сути приходится для этого делать какой-то реверс-инжиниринг. Монолитность веб-страниц для меня была непереносима, т.к. я привык жить по-другому в программировании. В моём понимании, должен быть некий конструктор, состоящий из повторно используемых компонентов, из которых собирается приложение. Ведь даже в одном сайте много страниц, а скажем, меню навигации нужно на каждой странице. На ванильном js это как-то не так уж удобно делать (на мой дилетантский взгляд). Насколько успешно vue решает эту задачу - это уже другой вопрос (на мой взгляд - не фонтан).

Man nuxt.js и иже.

Фрэймворк для фрэймворка. Лол.

В моём понимании, должен быть некий конструктор, состоящий из повторно используемых компонентов, из которого собирается приложение.

Такие конструкторы есть. Например, ExtJS от компании Sencha. Правда, стоит он довольно дорого, но дешевле, чем 32-битный LispWorks :-)

На ванильном js это как-то не так уж удобно делать (на мой дилетантский взгляд).

На мой взгляд, если человек не может написать на JavaScript свой собственный компонент (то же меню), то ему не следует заниматься созданием сколь-нибудь оригинальных web-интерфейсов с пользователем. Потому что рано или поздно возникнет задача (или фантазия), когда нужно будет действительно создать какой-то оригинальный компонент, а умения то и нет. И будет бедолага скитаться по Интернету в поисках готового компонента, вместо того, чтобы просто сделать свой собственный с высоко поднятой головой. Поэтому по мне так лучше мастерски владеть JavaScript/CSS/HTML, чем очередным кул-фреймворком, пусть даже если кул-фреймворк даст тебе фору по скорости изготовления примитивных ad-hoc решения для ширпотреба.

Вопрос не стоимости этой Sencha ExtJs, а её места на рынке. Ну, 5 вакансий на hh есть. Намного лучше, чем Lispworks, но намного хуже, чем vue :)

не может написать на JavaScript свой собственный компонент (то же меню)

Касаемо конкретно меню, пусть я остаюсь ретроградом, но я не вижу смысла писать его на JS. Это замедляет и утяжеляет страницу. Да, есть ещё медленный и дорогой интернет. В статических страницах и меню вполне может быть статическим. Т.е. уже в такой постановке задачи я вижу изъян. Может быть, я отстал от жизни. Но я именно того и искал - чтобы мне сгенерировали статическое (без JS) меню на серверной стороне. Вуй явно не про то, хотя на самом деле SSR позволяет с костылями это сделать.

Если идти дальше, то я ясно вижу, как корпорации воруют не только наши деньги, но ещё и наше время, что гораздо важнее. Они делают всё более и более тормозные технологии и заствляют нас постоянно апгрейдить железо, постоянно переучиваться на их новые идиотские задумки и искать костыли на замену того, за что мы уже раньше заплатили, к чему привыкли, и что у нас потом отобрали. Как они съедают батарейку моего мобильного устройства, которая мне нужна для других задач.

Меню на JS - это из этой серии.

Вопрос не стоимости этой Sencha ExtJs, а её места на рынке. Ну, 5 вакансий на hh есть. Намного лучше, чем Lispworks, но намного хуже, чем vue :)

Ок. А теперь посмотри на количество вакансий, где нужен скилл на JavaScript в общем. Намного больше, чем Vue.

Касаемо конкретно меню, пусть я остаюсь ретроградом, но я не вижу смысла писать его на JS. Это замедляет и утяжеляет страницу.
Если идти дальше, то я ясно вижу, как корпорации воруют не только наши деньги, но ещё и наше время, что гораздо важнее.

Вот поэтому я ратую за инвестирование времени в фундаментальный скилл, например, JavaScript/CSS/HTML, а не в кул-фреймворки, которых уже сменилось по нескольку десятков или сотен за последние 10-15 лет. И тогда можно решать задачи так, как нужно конкретно тебе - хочешь - меню на голом HTML/CSS, а хочешь 3D-меню на WebGL. Единственные серьёзные ограничения при таком подходе - это скилл и время.

А мне решать задачи не нужно. Это нужно рынку труда/заказов.

А мне задачи не нужны. Задачи нужны рынку труда/заказов.

Ты ведь сам говорил, что не желающий быть лидером будет вынужден вкалывать на других. Если ты решаешь задачи, нужные рынку труда, то тебе должно быть безразлично как писать меню - ты исполнитель, как скажут, так и будешь писать. Иначе не дадут денег.

Касаемо конкретно меню, пусть я остаюсь ретроградом, но я не вижу смысла писать его на JS.

Рынку труда/заказов ретрограды не нужны.

Думаю, я ответил на твой вопрос, какие у меня были проблемы с vue. Это ты уже куда-то не в ту степь, давай без меня дальше :)

Думаю, я ответил на твой вопрос, какие у меня были проблемы с vue. Это ты уже куда-то не в ту степь, давай без меня дальше :)

Ок. Спасибо за ответ! Удачи! :-)

... Вот поэтому я ратую за инвестирование времени в фундаментальный скилл, например, JavaScript/CSS/HTML, а не в кул-фреймворки, которых уже сменилось по нескольку десятков или сотен за последние 10-15 лет. И тогда можно решать задачи так, как нужно конкретно тебе - хочешь - меню на голом HTML/CSS, а хочешь 3D-меню на WebGL. Единственные серьёзные ограничения при таком подходе - это скилл и время.

А одно другому не мешает. Если вы выбрали специализацию frontend-разработчика, то вам по-любому надо знать JavaScript/CSS/HTML, плюс, DOM - без этого никуда. Только вот SPA-сайт чисто на таком наборе уже не сделаешь - для этого и служат «тяжелые» фреймворки типа Vue.js и пр. Ну а если речь идет о каких-то UI-элементах и динамических эффектах в рамках отдельных страниц классического сайта, то тут можно и чисто «фундаментальными скилами» обойтись, ну или какой-нибудь jQuery задействовать.

Это так... просто замечание - не для очередной длинной дискуссии )

Если вы выбрали специализацию frontend-разработчика, то вам по-любому надо знать JavaScript/CSS/HTML, плюс, DOM

Я выбрал профессию программиста. JS/CSS/HTML/DOM - это все лишь часть того, что мне приходится знать по долгу службы. Но мне это только в удовольствие.

Только вот SPA-сайт чисто на таком наборе уже не сделаешь - для этого и служат «тяжелые» фреймворки типа Vue.js и пр.

Почему не сделаешь? Все это «тяжёлые» фреймворки генерят всё тот же код на JS/CSS/HTML, затем интегрируют его в DOM. Эти фреймворки служат лишь для автоматизации в некоторой степени этой генерации и интеграции. Это как таблица виртуальных функций в C++ генерится автоматически из объявлений, но всё тоже самое можно сделать руками на чистом C. Только вот C++ - это промышленный стандарт, а Vue - всего лишь очередной генератор, коих десятки. А десятки их потому, что их авторы владеют фундаментальными основами. Следовательно, владея фундаментальными основами можно по-быстрому написать свой генератор под конкретную задачу, а не приспосабливаться под готовый ширпотреб-фрейморк.

Если вы выбрали специализацию frontend-разработчика, то вам по-любому надо знать JavaScript/CSS/HTML, плюс, DOM

Я выбрал профессию программиста...

Ну, раз вы себя позиционируете как «программиста» - без всяких узких специализаций, - то это предъявляет к вам повышенные требования относительно правильного выбора инструментов для решения конкретных задач (включая выбор операционной системы, языка программирования, всяких библитек-фреймворков, уже готового ПО и пр.). К примеру, вряд ли можно назвать квалифицированным программистом того, кто норовит писать абсолютно все задачи исключительно на Си. Си-программистом — это да (возможно даже супер Си-программистом), а вот «программистом» в более глобальном смысле - рановато будет :)

Только вот SPA-сайт чисто на таком наборе уже не сделаешь - для этого и служат «тяжелые» фреймворки типа Vue.js и пр.

Почему не сделаешь? Все это «тяжёлые» фреймворки генерят всё тот же код на JS/CSS/HTML, затем интегрируют его в DOM...

Сделать-то вы сделаете — только кому всё это нужно? Это ж всё сопровождать нужно будет потом, причем, заниматься этим будут, возможно, совсем другие люди. Объем исходников здесь будет существенно больше, чем просто какая-нибудь Javascript-примочка на отдельной страничке. А, стало быть, исходный код должен быть читабельным, хорошо структурированным, ну и компактным тоже... Тот же Vue.js предоставляет такие возможности, а вот гольный JavaScript/CSS/HTML/DOM – заведомо НЕТ.

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