Раньше: умеешь верстать? Отлично, ты принят В будущем: так, вот тебе задача, нужно создать социальную сеть, как в фейсбуке. Развени кластера, продумай всё, сделай так, чтобы оно могло ежесекундно обслуживать миллионы людей. Это твоё тестовое. Время тебе до послезавтра
Ага,) вроде и людей становится больше и автоматизация увеличивается, но почему то свободного времени всё меньше и меньше. Правильно, ведь надо тратить избыточную энергию для создания избыточной продукции, которая будет утилизировать в капиталистических войнах.
По моему это только удобство для прототипов. В целом, если бэк и фронт рядом, то такой агрегатор ускорит ответ. Вот только обычно, лучше завести такой агрегатор сразу на бэке. Получается агрегатор только для прототипов. И именно в ситуации когда заказчик сам не понимает чего хочет, и дизайн/логика компонента несколько раз меняются, такой быстрый способ собрать нужный запрос будет полезен. Прокси тоже вроде как уместен, но нельзя прокидывать заголовки, как в обычном route.ts крч. не выглядит как крутая фича. Фактически убирается несколько строк бойлерплейта лишая гибкости явного фетча. Но какбы фетчи и new Response и так в фабрики заворачиваются, не теряя их гибкости. т.ч. хз. реально только при создании демок, для ускорения понимания, какой интерфейс нужен в методе, который, всёравно, бэкэндщик будет делать на замену этим костылям.
@@arman-6172 я не про кривые данные, а именно про исключение на стороне серверного кода. Их можно поймать с помощью ErrorBoundary и отрисовать фаллбек. Как это работает? Некст присылает по http статус код 400 с стеком ошибки и упавшим оригинальным кодом. Вариант на самом деле не очень, супер не безопасно и работает странно, но такая возможность есть
@@kulakofft4 нет, предлагаю исключения кидать и ловить на проблемы с кодом и инфраструктурой, а не то что юзер пароль криво написал. Тут инструмент валидации должен подключаться и сообщать, а не валить приложение. Да и чтоб провалидировать несколько полей сразу нужно будет буфер какой поднимать, а потом что и куда? Опять же могу ошибаться, но выглядит как злостный костыль 🤷♂️
Очень печально что это становиться новым камнем преткновения react-а. Хоть я и back c#, но скажи мне сейчас на собесе что проект на next, я бы как минимум денек подумал, а если бы был другой оффер с чистым react-ом, то скорее всего выбрал бы его. Очень сложно гонять один проект как front и back, как буд-то react теряет свою чистоту и аккуратность.
На великих проектах ніхто не буде бізнесову логіку реалізовувати на nextjs. І не react, і не nextjs не ставлять собі це за мету. Проте є нюанси з перформансом, коли окремий сервер для фетчінгу даних -- це зайва ланка на шляху контента. Або навпаки (коли є окремий сервер), є headless-CMS, креди до якої на фронт передавати не можна (з різних причин) -- то ж і створили цю монстру React Server Components -- але це все одно фронт-енд, просто з рендером на сервері. Щодо чистоти ... nextjs вже йде з транспайлером та бандлером, з самого початку йшов. То ж, в якомусь сенсі це давно вже не просто реакт, і не просто нода -- це реакт + нода + (умовно) вебпак. З іншого боку їх команда робить все, щоб сам код був якомога більше бізнес-орієнтованим (звісно в частині рендеру), і не мав великої кількості зав'язок, ні на реакт, ні на nextjs. Але на практиці, це стає занадто "магічним" особливо для початківців.
Ем... А как другие клиенты будут пользоваться всем этим го... добром? Ну, к примеру, у нас есть 3-4 клиента - веб, iOS, Android, еще какой-нибудь Расбери Пай, плюс внешний сервис хочет интегрироваться с нами и юзать наш бекенд. С REST API все просто, а с React Server Actions как такое провернуть?
@@it-sin9k Ну а если клиент - не браузер? Сервер, к примеру. Или ресолвер GraphQL. Или мобильное приложение, написанное на Kotlin, или Swift, или Dart? Или десктопное приложение, что по сети у нашего сервера данные получает? Ну и так далее...
ааа я понял о чем вы. Конкретно эти же эндпоинты использовать точно нельзя. Но тут несколько моментов, под другие девайсы делают другой дизайн и ендпоинты все равно свои пилят. Поэтому может быть промежуточный бек позади nextJS, который все это сделает. Либо не пользоваться конкретно этой фичей и пользоваться только Server COmponents.
@@it-sin9k Просто удивляет настойчивость фейсбука, с которой они стараются "переизобрести" уже хорошо работающие вещи, по типу PHP или RPC, - но которые уже хорошо отлажены и могут использоваться в огромном количестве кейсов. Пока что получается так себе... Впрочем, возможно они решают какие-то свои локальные проблемы, просто результаты попадают в открытий доступ. Но они при этом не говорят об истинных причинах своих решений, и местами они выглядят странно.
И ведь найдётся идиот, вышедший с онлайн курсов, который начнёт пилить небольшой проект на этом говне для какого-то бизнеса. Итог - засранный код с нулевой масштабируемостью. А когда захотят функционал посложнее чем стандартный круд добавить - охренеет от жизни. Зато заказчики будут думать, что разрабатывать так просто.
я бы сказал, что текущее решение на уровне обычного POST запроса, лучше все равно пока ничего не придумали. По поводу управлять, я таких опций не видел. Думаю пока их и нет. И не понятно понадобятся ли :)
@@it-sin9k ну есть ли профит какой-то использовать некст с сервер экшенами если у тебя весь бэк отдельный и дб там же отдельно. Или тогда лучше просто делать CSR на реакте например.
Конечно есть. Пусть ваш Next отправляет запросы на ваш отдельный бэк и вы по прежнему польхуетесь благами серверного рендеринга и у вас хорошо отделена логика бэкэнда
А может лучше fastify? В ней есть type-providers, принцип тот же как что в TRPC: пишешь схему валидации, из нее автоматом выводятся типы и openapi схема. А из openapi уже можно сгенерировать клиент для любого нужного тебе языка. Хотя в TRPC чуть меньше телодвижений будет. Но разница на самом деле не велика, в любом случае большую часть времени займет описание схемы валидации.
Так fastify - это полноценный веб сервер, там много лишнего и получается привязка к нему, а trpc - это только про типизацию взаимодействия и его можно интегрировать с любыми бэкенд/фронтенд фреймворками на nodejs/deno/etc.
прошу прощения, но по моему глупость возвращать 400 ответ если у тебя что-то там не срослось и ты можешь вернуть нормальный 200 ответ. просто возвращаешь json error=0|1, result: {...} раз тут уже все инкапсулировали в виде вызова функции, тут вообще не должно быть 400 ошибки, это тут вообще не нужно
@@it-sin9k это да, только зачем в ответе если там ничего не сломалось возвращать 4хх ? это вообще серверные ошибки, если страницы нет, или внутренняя ошибка, если запрос нормально прошел, мне кажется должно быть 200 всегда, и уже в ответе возвращаем статус нашей бизнес логики, так сказать на программном уровне, все ли нормально и если запрашивали ответ, его тоже возвращаем.
Попробовал экшены с ORM. Как ловить ошибки и обрабатывать? Потому что если даже появляется ошибка, то я ее не вижу и в catch не ловится, а просто получаю SyntaxError: Unexpected identifier. Очень странно. Даже обычный console.log(true) не выводит. Просто у меня запрос проходит и в БД добавляется запись, а все повторные падают с этой ошибкой пока проект не пересоберу через Ctrl + S. Вы случайно не знаете эту проблему?
@@it-sin9k По сути это было бы вполне логичным развитием php, но Js к этому пришел раньше. Впрочем, думаю подобная технология вполне может быть пригодной на больших проектах. Было бы интересно, если бы это решение ещё сразо включала в себя ORM для работы с БД. При этом, безопасность вполне решаемая проблема. Единственное, из-за того, что так просто и "сладко" делать запросы на сервер люди будут злоупотреблять этим и реже кешировать результаты, из-за чего во время перерисовок будет куча запросов
@@vas_._sfer6157, а зачем вам лочиться на ORM от Vercel? Есть множество решений вроде Prisma или Drizzle. У Prisma есть встроенные стратегии кэширования, но ничего не мешает вам реализовать свою или использовать стороннюю
@@it-sin9k ну в заставках-перебивках, у адоба такой глюк, что на некотрых кирилических шрифтах у него растояние между буквами слишком большое, поэтому и спросил
И до этого в нексте можно было написать бэк апишку. Только запрсы к ней делать нужно было через фетч. А сейчас просто сделали более красивое и понятное решение. Весь хейт в сторону некста это просто боязнь принимать новые правила и не чем не обоснован. Для создания маленьких проэктов некст стает просто ультимативным решением👍
И да и нет. Мы теперь должны знать как правильно готовить backend. Должны четко понимать какие части кода где выполняются (что выполняется на клиенте, а что выполняется на сервере); как покрывать сервер аналитикой, метриками и алертами; должны знать как решать проблемы при падении приложения; должны знать про потребление ресурсов нашим сервером и уметь оптимизировать; должны знать как обеспечить отказоустойчивость (как настроить и запустить несколько инстансов в нескольких ДЦ) и многое многое другое. И на каждом из этих этапов очень легко допустить ошибку, которая будет стоит компаниям денег. Раньше все это можно было делегировать backend-разработчикам (которые в этих темах давно и профессионально) и заниматься чисто фронтовой работой (ведь и чисто фронтовой работы очень-очень много и она бывает очень-очень сложная) Т.е. да, если заниматься простыми проектами, pet-проектами, или проектами с малой нагрузкой то все супер. Очень многих проблем просто не возникает. А разработка, видимо, становится более приятной и убодной. Но в серьезных проектах это все может и будет приводить к проблемам.
@@kirill-eremin, это еще до SC и SA было. Поэтому ничего особо не изменилось. В крупных проектах SSR фреймворки вроде Next, Vite и SvelteKit были и будут как BFF. Бэкенд будет жить отдельно.
Более понятное решение? "Ведь как оно работает, понять непросто" - цитата из видео. Весь хейт в сторону некста это просто люди уже словили кактусов на паре проектов. Не понимаю, почему и дальше это продолжают пропагандировать.
Для классической конфигурации фронт + бэк не обязательно делать два репозитория, по одному на каждое приложение. Монорепозитории как раз для таких задач и сделаны - все приложения в одном репозитории, зависимости устанавливать можно отдельно для каждого, запускать можно отдельно каждое, очень удобно. Единственный минус - огромные проекты с сотнями тысяч коммитов будут долго клонироваться в первый раз
![Tee Grizzley - Blow for Blow (feat. J. Cole) [Official Video]](http://i.ytimg.com/vi/wNLN5xsx5dc/mqdefault.jpg)
![DDG & G Herbo - Nosey [Official Video]](http://i.ytimg.com/vi/I9Ra0Zc2NlQ/mqdefault.jpg)
О да, как я люблю статус код 200 с полем status 'Bad request' и code 400 внутри. какой же кайф
Раньше: умеешь верстать? Отлично, ты принят
В будущем: так, вот тебе задача, нужно создать социальную сеть, как в фейсбуке. Развени кластера, продумай всё, сделай так, чтобы оно могло ежесекундно обслуживать миллионы людей. Это твоё тестовое. Время тебе до послезавтра
да) мне как то на тестовое попросили написать целый проект для аренды мотороллеров) чет я прифигел от этого))
Ага,) вроде и людей становится больше и автоматизация увеличивается, но почему то свободного времени всё меньше и меньше. Правильно, ведь надо тратить избыточную энергию для создания избыточной продукции, которая будет утилизировать в капиталистических войнах.
Поздравляю, вы открыли RPC.
РПЦ?
@@FailValiev, Remote Procedure Call (RPC)
@@infantfrontender6131калл из процедур
православненько)))))
По моему это только удобство для прототипов.
В целом, если бэк и фронт рядом, то такой агрегатор ускорит ответ. Вот только обычно, лучше завести такой агрегатор сразу на бэке.
Получается агрегатор только для прототипов. И именно в ситуации когда заказчик сам не понимает чего хочет, и дизайн/логика компонента несколько раз меняются, такой быстрый способ собрать нужный запрос будет полезен.
Прокси тоже вроде как уместен, но нельзя прокидывать заголовки, как в обычном route.ts
крч. не выглядит как крутая фича. Фактически убирается несколько строк бойлерплейта лишая гибкости явного фетча. Но какбы фетчи и new Response и так в фабрики заворачиваются, не теряя их гибкости.
т.ч. хз. реально только при создании демок, для ускорения понимания, какой интерфейс нужен в методе, который, всёравно, бэкэндщик будет делать на замену этим костылям.
Как вариант по работе с ошибками, можно вызывать exception в экшене через throw и на клиенте ловить с помощью ErrorBoundary компонента и это работает
Спасибо! надо попробовать)
Кривые юзерские данные это не исключение 🤔. Хотя может на каких-то ЯП такое практикуют
@@arman-6172 я не про кривые данные, а именно про исключение на стороне серверного кода. Их можно поймать с помощью ErrorBoundary и отрисовать фаллбек. Как это работает? Некст присылает по http статус код 400 с стеком ошибки и упавшим оригинальным кодом. Вариант на самом деле не очень, супер не безопасно и работает странно, но такая возможность есть
@@arman-6172 имеешь ввиду сервер должен отвечать 200 на кривые данные?
@@kulakofft4 нет, предлагаю исключения кидать и ловить на проблемы с кодом и инфраструктурой, а не то что юзер пароль криво написал. Тут инструмент валидации должен подключаться и сообщать, а не валить приложение. Да и чтоб провалидировать несколько полей сразу нужно будет буфер какой поднимать, а потом что и куда? Опять же могу ошибаться, но выглядит как злостный костыль 🤷♂️
это гениаольно, зря я не смотрел тебя раньше, я бы сейчас былбы суперменом в мире фронтов магий nextjs
Ух, эта боль джавистов. Неужели через год другой останется только js 🥰
да, хлеб потихоньку отбираем)
Очень печально что это становиться новым камнем преткновения react-а. Хоть я и back c#, но скажи мне сейчас на собесе что проект на next, я бы как минимум денек подумал, а если бы был другой оффер с чистым react-ом, то скорее всего выбрал бы его. Очень сложно гонять один проект как front и back, как буд-то react теряет свою чистоту и аккуратность.
На великих проектах ніхто не буде бізнесову логіку реалізовувати на nextjs. І не react, і не nextjs не ставлять собі це за мету. Проте є нюанси з перформансом, коли окремий сервер для фетчінгу даних -- це зайва ланка на шляху контента. Або навпаки (коли є окремий сервер), є headless-CMS, креди до якої на фронт передавати не можна (з різних причин) -- то ж і створили цю монстру React Server Components -- але це все одно фронт-енд, просто з рендером на сервері.
Щодо чистоти ... nextjs вже йде з транспайлером та бандлером, з самого початку йшов. То ж, в якомусь сенсі це давно вже не просто реакт, і не просто нода -- це реакт + нода + (умовно) вебпак.
З іншого боку їх команда робить все, щоб сам код був якомога більше бізнес-орієнтованим (звісно в частині рендеру), і не мав великої кількості зав'язок, ні на реакт, ні на nextjs. Але на практиці, це стає занадто "магічним" особливо для початківців.
@@TheSky5028для особо одаренных, снизу есть кнопка translate to Russian
@@TheSky5028 лови репорт за расизм)
@@artem_bohakно ведь... Это же национализм...
@@KhikmatjonAzizov на пк нет
Ну в некоторых случаях будет полезны server actions ну а так rest api бекенд будете жить долго думаю
rest точно никуда не денется)
Ем... А как другие клиенты будут пользоваться всем этим го... добром? Ну, к примеру, у нас есть 3-4 клиента - веб, iOS, Android, еще какой-нибудь Расбери Пай, плюс внешний сервис хочет интегрироваться с нами и юзать наш бекенд. С REST API все просто, а с React Server Actions как такое провернуть?
не уверен, что понял вопрос. Пользоваться как? если через браузер открывать сайт, то какая разница, на любом устройстве откроет
@@it-sin9k Ну а если клиент - не браузер? Сервер, к примеру. Или ресолвер GraphQL. Или мобильное приложение, написанное на Kotlin, или Swift, или Dart? Или десктопное приложение, что по сети у нашего сервера данные получает? Ну и так далее...
ааа я понял о чем вы. Конкретно эти же эндпоинты использовать точно нельзя. Но тут несколько моментов, под другие девайсы делают другой дизайн и ендпоинты все равно свои пилят. Поэтому может быть промежуточный бек позади nextJS, который все это сделает. Либо не пользоваться конкретно этой фичей и пользоваться только Server COmponents.
@@it-sin9k Просто удивляет настойчивость фейсбука, с которой они стараются "переизобрести" уже хорошо работающие вещи, по типу PHP или RPC, - но которые уже хорошо отлажены и могут использоваться в огромном количестве кейсов. Пока что получается так себе... Впрочем, возможно они решают какие-то свои локальные проблемы, просто результаты попадают в открытий доступ. Но они при этом не говорят об истинных причинах своих решений, и местами они выглядят странно.
И ведь найдётся идиот, вышедший с онлайн курсов, который начнёт пилить небольшой проект на этом говне для какого-то бизнеса.
Итог - засранный код с нулевой масштабируемостью. А когда захотят функционал посложнее чем стандартный круд добавить - охренеет от жизни.
Зато заказчики будут думать, что разрабатывать так просто.
Как прототип накидать или простой проект - штука нормальная. Потом надо выкинуть и сделать нормально.
Логин и пароль передались в открытом виде через GET или POST запросом? И можно ли этим управлять?
Спасибо заранее за ответ)))
я бы сказал, что текущее решение на уровне обычного POST запроса, лучше все равно пока ничего не придумали. По поводу управлять, я таких опций не видел. Думаю пока их и нет. И не понятно понадобятся ли :)
Как думаете, в проде реально будут этим пользоваться?
Нет конечно
ну все кто NextJS завезли себе в проект, те будут
а насколько это вообще все имеет смысл если использовать отдельный бэкенд с некстом для SSR, SSG и прочих его прелестей?
не очень уловил суть вопроса
@@it-sin9k ну есть ли профит какой-то использовать некст с сервер экшенами если у тебя весь бэк отдельный и дб там же отдельно. Или тогда лучше просто делать CSR на реакте например.
Конечно есть. Пусть ваш Next отправляет запросы на ваш отдельный бэк и вы по прежнему польхуетесь благами серверного рендеринга и у вас хорошо отделена логика бэкэнда
так я не уловил с этого экшена нельзязапрос базе данных отправить? если нет то это чуток бесполезняво
можно отправить запрос к базе данных) можно сделать абсолютно все, что делают на бэкэнде)
@@it-sin9k имба тогда)
Может лучше сразу взять tRPC ?
не знаком с такой абривиатурой о_О
А может лучше fastify? В ней есть type-providers, принцип тот же как что в TRPC: пишешь схему валидации, из нее автоматом выводятся типы и openapi схема. А из openapi уже можно сгенерировать клиент для любого нужного тебе языка.
Хотя в TRPC чуть меньше телодвижений будет.
Но разница на самом деле не велика, в любом случае большую часть времени займет описание схемы валидации.
Так fastify - это полноценный веб сервер, там много лишнего и получается привязка к нему, а trpc - это только про типизацию взаимодействия и его можно интегрировать с любыми бэкенд/фронтенд фреймворками на nodejs/deno/etc.
❤❤❤🎉🎉🎉
ретарн
ретард
С dts слышно синяка в правом ухе =)
да) это косяк при записе) сори)
прошу прощения, но по моему глупость возвращать 400 ответ если у тебя что-то там не срослось и ты можешь вернуть нормальный 200 ответ. просто возвращаешь json error=0|1, result: {...} раз тут уже все инкапсулировали в виде вызова функции, тут вообще не должно быть 400 ошибки, это тут вообще не нужно
протокол общения с серверными экшенами еще только зарождается) поэтому можем эксперементировать!)
@@it-sin9k это да, только зачем в ответе если там ничего не сломалось возвращать 4хх ? это вообще серверные ошибки, если страницы нет, или внутренняя ошибка, если запрос нормально прошел, мне кажется должно быть 200 всегда, и уже в ответе возвращаем статус нашей бизнес логики, так сказать на программном уровне, все ли нормально и если запрашивали ответ, его тоже возвращаем.
где тайпскрипт? умер?
А что с ним не так?)
@@it-sin9k не используется в видео в примерах, значит и в работе не советуешь?)
Попробовал экшены с ORM.
Как ловить ошибки и обрабатывать? Потому что если даже появляется ошибка, то я ее не вижу и в catch не ловится, а просто получаю SyntaxError: Unexpected identifier.
Очень странно. Даже обычный console.log(true) не выводит.
Просто у меня запрос проходит и в БД добавляется запись, а все повторные падают с этой ошибкой пока проект не пересоберу через Ctrl + S.
Вы случайно не знаете эту проблему?
можете набросать пример проблемы на github? попробуем посмотреть)
@@it-sin9k оказывается все это время мой 2-ой коммент с ссылкой ютуб не прикреплял(. На гитхабе woodjs проект car-shop
Ага, жаль только, что некст - просто хайповое г..но
Angular или VueX лучше во всех случаях ? 🙂
@@user-uv4rk1vt7x эм... А при чем тут Next и "Angular или VueX"🤔
Жаль не это, а что реакт подминают.
@@golden_smiles react был есть и будет. А для сср будет куча альтернатив нексту в ближайшем будущем. То же астро.
@@golden_smiles подмяли реакт
next-safe-action - используем эту либу для хендлинга статусов и ошибок в серверных экшенах
Выглядит всё это конечно не очень безопасно
мне кажется или правая дорожка звучит громче?
блин, я думал у меня наушники сломались)
блин, а при записи я думал это у меня немного глючат наушники :(
С телефона норм😅
Слышал про ретёрн, ретурн, но ретарн впервые ))
Meteor, старина, ты вернулся немного в другом лице)
Для to do list пойдет )
Какая боль по звуку, аудиодорожка только с голосом только в правое ухо идет.
Но лайк за видео
Спасибо! и сорри за звук) переустанавливал ПО и думал это у меня наушники сбоят) а оказалось ПО плохо настроил)
3:49 return - это не ретАрн, а ретЁрн. А по-правильному вообще звучит как «ретёён» 🧐
Благодарю за видео 🤘
кто нибудь, откройте форточку
Изобрели php в javascript...
Какой кошмар. 🤮🤮🤮
От чего бежали, туда и вернулись в итоге.
а на php сразу делали клиент плюс сервер? (я просто не шарю)
на пхп скорее делали сервер и + клиент) это имело чуть другие результаты)
Вордпресс
@@it-sin9k По сути это было бы вполне логичным развитием php, но Js к этому пришел раньше. Впрочем, думаю подобная технология вполне может быть пригодной на больших проектах.
Было бы интересно, если бы это решение ещё сразо включала в себя ORM для работы с БД.
При этом, безопасность вполне решаемая проблема.
Единственное, из-за того, что так просто и "сладко" делать запросы на сервер люди будут злоупотреблять этим и реже кешировать результаты, из-за чего во время перерисовок будет куча запросов
@@vas_._sfer6157, а зачем вам лочиться на ORM от Vercel? Есть множество решений вроде Prisma или Drizzle. У Prisma есть встроенные стратегии кэширования, но ничего не мешает вам реализовать свою или использовать стороннюю
Поглощают от слова глотать.
поправил) спасибо!)
php вас настиг
звук только в правом канале
Сорри за это, мой косяк)
а что на счет шифрования ?
логин и пароль где-то в чистом виде летят на сервер?
А как вы шифруете обычно логин пароль до отправки на сервер?
@@it-sin9k да я затупил, ведь под капотом то всё тот же https запрос 🤭
Монтажер, тебя не смущают такие кривые русские шрифты?
Если дадите чуть более конкретные советы, мы были бы рады)
@@it-sin9k из-за кривого шрифта у вас расстояние между буквами двойное. Адоб?
а можешь чуть конкретнее указать на какой секунде, что смущает, а то пока тяжело понять о чем речь
@@it-sin9k ну в заставках-перебивках, у адоба такой глюк, что на некотрых кирилических шрифтах у него растояние между буквами слишком большое, поэтому и спросил
серверные экшены больше про progressive enhancement
а это востребованая фича вообще progressive enhancement?
@@it-sin9k, на уровне UX. Людей отключающих JS в браузере очень мало, но я не вижу каких либо проблем в том SA привносят progressive enhancement.
И до этого в нексте можно было написать бэк апишку. Только запрсы к ней делать нужно было через фетч. А сейчас просто сделали более красивое и понятное решение. Весь хейт в сторону некста это просто боязнь принимать новые правила и не чем не обоснован. Для создания маленьких проэктов некст стает просто ультимативным решением👍
И да и нет.
Мы теперь должны знать как правильно готовить backend.
Должны четко понимать какие части кода где выполняются (что выполняется на клиенте, а что выполняется на сервере); как покрывать сервер аналитикой, метриками и алертами; должны знать как решать проблемы при падении приложения; должны знать про потребление ресурсов нашим сервером и уметь оптимизировать; должны знать как обеспечить отказоустойчивость (как настроить и запустить несколько инстансов в нескольких ДЦ) и многое многое другое. И на каждом из этих этапов очень легко допустить ошибку, которая будет стоит компаниям денег. Раньше все это можно было делегировать backend-разработчикам (которые в этих темах давно и профессионально) и заниматься чисто фронтовой работой (ведь и чисто фронтовой работы очень-очень много и она бывает очень-очень сложная)
Т.е. да, если заниматься простыми проектами, pet-проектами, или проектами с малой нагрузкой то все супер. Очень многих проблем просто не возникает. А разработка, видимо, становится более приятной и убодной. Но в серьезных проектах это все может и будет приводить к проблемам.
@@kirill-eremin, это еще до SC и SA было. Поэтому ничего особо не изменилось.
В крупных проектах SSR фреймворки вроде Next, Vite и SvelteKit были и будут как BFF. Бэкенд будет жить отдельно.
Более понятное решение? "Ведь как оно работает, понять непросто" - цитата из видео. Весь хейт в сторону некста это просто люди уже словили кактусов на паре проектов. Не понимаю, почему и дальше это продолжают пропагандировать.
Для классической конфигурации фронт + бэк не обязательно делать два репозитория, по одному на каждое приложение. Монорепозитории как раз для таких задач и сделаны - все приложения в одном репозитории, зависимости устанавливать можно отдельно для каждого, запускать можно отдельно каждое, очень удобно. Единственный минус - огромные проекты с сотнями тысяч коммитов будут долго клонироваться в первый раз
Каналу вроде не первый год, а до сих пор приводит такие жалкие и нелепые примеры. Бекенд у него для формы регистрации без БД :D
хмм, а почему решили, что там нет бд?
Так примеры для новичков
Если вы опытный разработчик, просто пройдите мимо