про frontend, sse, websocket и прочее. Поделитесь опытом.
Господа, опытные разработчики, если не лень, поделитесь опытом правильной современной веб разработки.
Речь о разработке с четким разделением фронтенда и бекенда, где на фронтенде реализована spa шка например на vue, а бекенд это rest api, например на php.
Постараюсь сформулировать четкие вопросы, чтобы получить четкие ответы.
1) При обращении по любому урлу сервер отдает пользователю пустой html документ в которой есть js скрипт.
Все это загрузилось на клиент, js скрипт содержит код на vue и например на хук жизненого цикла там подвеешены fetch запросы на api для получения всех необходимых данных для страницы. Данные получили, vue отрендерил это в виде html в корневой элемент. Это понятно.
Как вы реализуете дальнейшей взаимодействие пользователя со страницей? Я так понимаю что для примитивных задач, типа кликнул на товар, открылось модальное окно с детальной карточкой товара, обычно используют простые eventListener ы? На событие клик, отправили новый запрос на api, получили новые данные, отрендеририл или новый vue компонет или за счет реактивности данных сразы изменился какой-то из существующих. Так поступают?
2) Но если проект понагруженнее, что если 10 000 пользователей постоянно кликают по всем кнопкам, то все оставляем так же? Постоянно запросы на api? Или же выгоднее открывать соединение по вебсокет? Есть у кого реальный опыт использование как http запросов с клиента на сервер, так и реализации такого же на вебсокетах? Если да, то как правильно — при загрузке страницы мы получаем первоночально данные по fetch запросу, а потом уже открываем вебсокет соединение и обмениваемся далее данными по этому каналу. Или же сразу на кухе mounted открываем веб сокет соединение и даже первоночальные данные получаем по нему?
3) мне как бекендщику кажется, что сама технология работы по протоколу websocket довольно затратная вплане ресурсов для сервера. 10 000 открытых веб сокет соединений могут стать проблемой даже большей, чем постоянный долбеж сервер http запросами на api на каждый чих и клик. Хорошей альтернативой выглядит технология SSE (server send event), которая позволяет куда менее затратно держать открытый канал клиент сервер, но работает только в одну сторону — от сервера на клиент. Кто то использует при проектировании frontend приложений?
4) Я правильно понимаю, что websocket это протокол на базе tсp, а не http? Получается, через него можно перегонять только данные в чистом виде, например json, но не https запросы. Но как вы тогда (если конечно вы используете вебсокеты для работы spa шок) решаете вопросы с авторизацией? кодами ответа? Заголовками? Ведь в современной веб разработке очень большую роль играет код ответа от сервера, наши авториазции во многом построены на передаче в заголовках авторизационных токенов и так далее. И всего этого получается мы лишены при общении через websocket? Как тогда убедится, что данные, пришедшие от клиента на сервер через websocket действительно пришли от супер админа и их нужно сохранить в базу?
Понимаю, что сумбурно, но уж простите)
Так же приветствуются рассказы как организованы подобные проекты у вас. Желательно без излишей жаргонщины, типа «да у меня vuex c vue и все пропсами через стейты по composition api» работает. Я даже скорее всего вас пойму, но все же приветствую более простой пока язык.
Ну и для обсуждения.
У меня сложилось мнение, что современный frontend даже в 2023 году все еще не production-ready решение.
Я понимаю, что это мнение дилетанта и я бы ничего не говорил, если бы не пообщался с более менее опытными frontendщиками немного. И меня удивил тот факт, что многие задачи их ставят просто в тупик. Все прекрасно знают как написать to-do приложение на vue, react или svelte (и я тоже могу), но задачи из реального большого проекта многих пугают просто. Все кричат что вью роутер это круто, что spa это будущее, но когда оказывается что на проекте нужно около 700 различных рутов то оказывается что роутер тормозит безбожно и фронтендщики говорят — ну не получилось, давайте значит делать не spa, пусть за руотинг отвечает сервер…
Короче говоря, какое то ощущение в мире фронтенда легкой эйфории, которая на прикатике разбивается сразу же, когда проект становится сложнее чем to-do пример. Вон timeweb с гордостью сообщали недавно что переписали весь интерфейс на реакте. И на мой взляд стало все тормозить намного больше.
В общем буду рад вашим советам, о том — какая она «правильная» frontend разработка в 2023 году? (но сразу скажу, ответы типа «установи vite, запусти команду и больше ни о чем не думай», я не очень люблю. Я люблю глубоко разбиратся в технологиях с которыми работаю, а не скользить по поверхности).
Речь о разработке с четким разделением фронтенда и бекенда, где на фронтенде реализована spa шка например на vue, а бекенд это rest api, например на php.
Постараюсь сформулировать четкие вопросы, чтобы получить четкие ответы.
1) При обращении по любому урлу сервер отдает пользователю пустой html документ в которой есть js скрипт.
Все это загрузилось на клиент, js скрипт содержит код на vue и например на хук жизненого цикла там подвеешены fetch запросы на api для получения всех необходимых данных для страницы. Данные получили, vue отрендерил это в виде html в корневой элемент. Это понятно.
Как вы реализуете дальнейшей взаимодействие пользователя со страницей? Я так понимаю что для примитивных задач, типа кликнул на товар, открылось модальное окно с детальной карточкой товара, обычно используют простые eventListener ы? На событие клик, отправили новый запрос на api, получили новые данные, отрендеририл или новый vue компонет или за счет реактивности данных сразы изменился какой-то из существующих. Так поступают?
2) Но если проект понагруженнее, что если 10 000 пользователей постоянно кликают по всем кнопкам, то все оставляем так же? Постоянно запросы на api? Или же выгоднее открывать соединение по вебсокет? Есть у кого реальный опыт использование как http запросов с клиента на сервер, так и реализации такого же на вебсокетах? Если да, то как правильно — при загрузке страницы мы получаем первоночально данные по fetch запросу, а потом уже открываем вебсокет соединение и обмениваемся далее данными по этому каналу. Или же сразу на кухе mounted открываем веб сокет соединение и даже первоночальные данные получаем по нему?
3) мне как бекендщику кажется, что сама технология работы по протоколу websocket довольно затратная вплане ресурсов для сервера. 10 000 открытых веб сокет соединений могут стать проблемой даже большей, чем постоянный долбеж сервер http запросами на api на каждый чих и клик. Хорошей альтернативой выглядит технология SSE (server send event), которая позволяет куда менее затратно держать открытый канал клиент сервер, но работает только в одну сторону — от сервера на клиент. Кто то использует при проектировании frontend приложений?
4) Я правильно понимаю, что websocket это протокол на базе tсp, а не http? Получается, через него можно перегонять только данные в чистом виде, например json, но не https запросы. Но как вы тогда (если конечно вы используете вебсокеты для работы spa шок) решаете вопросы с авторизацией? кодами ответа? Заголовками? Ведь в современной веб разработке очень большую роль играет код ответа от сервера, наши авториазции во многом построены на передаче в заголовках авторизационных токенов и так далее. И всего этого получается мы лишены при общении через websocket? Как тогда убедится, что данные, пришедшие от клиента на сервер через websocket действительно пришли от супер админа и их нужно сохранить в базу?
Понимаю, что сумбурно, но уж простите)
Так же приветствуются рассказы как организованы подобные проекты у вас. Желательно без излишей жаргонщины, типа «да у меня vuex c vue и все пропсами через стейты по composition api» работает. Я даже скорее всего вас пойму, но все же приветствую более простой пока язык.
Ну и для обсуждения.
У меня сложилось мнение, что современный frontend даже в 2023 году все еще не production-ready решение.
Я понимаю, что это мнение дилетанта и я бы ничего не говорил, если бы не пообщался с более менее опытными frontendщиками немного. И меня удивил тот факт, что многие задачи их ставят просто в тупик. Все прекрасно знают как написать to-do приложение на vue, react или svelte (и я тоже могу), но задачи из реального большого проекта многих пугают просто. Все кричат что вью роутер это круто, что spa это будущее, но когда оказывается что на проекте нужно около 700 различных рутов то оказывается что роутер тормозит безбожно и фронтендщики говорят — ну не получилось, давайте значит делать не spa, пусть за руотинг отвечает сервер…
Короче говоря, какое то ощущение в мире фронтенда легкой эйфории, которая на прикатике разбивается сразу же, когда проект становится сложнее чем to-do пример. Вон timeweb с гордостью сообщали недавно что переписали весь интерфейс на реакте. И на мой взляд стало все тормозить намного больше.
В общем буду рад вашим советам, о том — какая она «правильная» frontend разработка в 2023 году? (но сразу скажу, ответы типа «установи vite, запусти команду и больше ни о чем не думай», я не очень люблю. Я люблю глубоко разбиратся в технологиях с которыми работаю, а не скользить по поверхности).