Забавно наблюдать, как статья начинается с классического «внешние ключи бесполезны», а заканчивается «ну, вообще FK можно использовать как дополнительную защиту». Чем громче заголовок, тем тише концовка.
Вы, конечно, вправе считать внешние ключи пережитком академического прошлого — особенно если вся практика ограничивается CRUD-приложениями, где один бэкенд и один разработчик «всё контролирует». Но, знаете, жизнь суровее лабораторных.
Жаль, не указали, где вы работаете. Не из любопытства, а чтобы я заранее знал, какими продуктами лучше не пользоваться: слишком страшно доверять системе, где консистентность данных держится исключительно на вере в идеальность бэкенда.
Маркетинг есть даже в ИТ. И он, к сожалению, работает. Сегодня у технологии, за которой не стоит крупная компания, шансы на взлет небольшие. А в бизнесе вообще беда. Если фронт, почти безальтернативно react (Facebook, vercel), если бэк, то какой нибудь go (google), python (вроде многие компании поддерживают), c# (MS). Особенно удивляет стремление всюду все сделать на микросервисах, ведь у всех, абсолютно у всех, только hiload.
Отсюда и проблемы у эликсира. Если прийти в компанию и сказать, что ты сделаешь то же самое, только без микросервисов (или меньшей декомпозицией) тремя разработчиками на эликсире вместо десяти go-разработчиков, с тобой не будут разговаривать, подумают, что сумасшедший. Hiload же
Не согласен. Старые серверные реализации возвращали целые страницы (html + css + js), либо куски страниц. Автор рассказывает о получении с сервера описания UI - то есть того же JSON. То если рисует все равно фронт. Я, например, сейчас принимаю участи в проекте, где UI построен по такому принципу. У нас фронт принимает набор полей с правилами (валидация, подсказки, порядок отрисовки, условная отрисовка), при этом контейнер, где UI рисовать, определяется фронтом. К слову, у Яндекса есть divkit, он вообще очень динамический. Если не ошибаюсь, такси и еда на нем сейчас, может что-то еще
Забавно наблюдать, как статья начинается с классического «внешние ключи бесполезны», а заканчивается «ну, вообще FK можно использовать как дополнительную защиту». Чем громче заголовок, тем тише концовка.
Вы, конечно, вправе считать внешние ключи пережитком академического прошлого — особенно если вся практика ограничивается CRUD-приложениями, где один бэкенд и один разработчик «всё контролирует». Но, знаете, жизнь суровее лабораторных.
Жаль, не указали, где вы работаете. Не из любопытства, а чтобы я заранее знал, какими продуктами лучше не пользоваться: слишком страшно доверять системе, где консистентность данных держится исключительно на вере в идеальность бэкенда.
Маркетинг есть даже в ИТ. И он, к сожалению, работает. Сегодня у технологии, за которой не стоит крупная компания, шансы на взлет небольшие. А в бизнесе вообще беда. Если фронт, почти безальтернативно react (Facebook, vercel), если бэк, то какой нибудь go (google), python (вроде многие компании поддерживают), c# (MS). Особенно удивляет стремление всюду все сделать на микросервисах, ведь у всех, абсолютно у всех, только hiload.
Отсюда и проблемы у эликсира. Если прийти в компанию и сказать, что ты сделаешь то же самое, только без микросервисов (или меньшей декомпозицией) тремя разработчиками на эликсире вместо десяти go-разработчиков, с тобой не будут разговаривать, подумают, что сумасшедший. Hiload же
Не согласен. Старые серверные реализации возвращали целые страницы (html + css + js), либо куски страниц. Автор рассказывает о получении с сервера описания UI - то есть того же JSON. То если рисует все равно фронт. Я, например, сейчас принимаю участи в проекте, где UI построен по такому принципу. У нас фронт принимает набор полей с правилами (валидация, подсказки, порядок отрисовки, условная отрисовка), при этом контейнер, где UI рисовать, определяется фронтом. К слову, у Яндекса есть divkit, он вообще очень динамический. Если не ошибаюсь, такси и еда на нем сейчас, может что-то еще