Доктор, ну успокойтесь Бога ради дорогой друг. Никто ведь не воюет с SPA. Вы давали клятву врача в конце концов.
Мы уважаем Ваш выбор фронтенда как основы.
Для того, чтобы понять — моя фраза «сомнительно» звучала недосказанно как «сомнительно лично для меня, но для других подходит» — не требуется давать клятву врача.
а кто говорит что «плохо»? Это мое отдельно взятое имхо, причем допускающее что для каких-то проектов и разработок удается использовать SPA как основу и проблем с этим нет.
Но, такой подход не всем подходит.
А слишком черно-бело смотреть на это (или это хорошо, или плохо) я не могу. Промежуточные градации тоже должны быть.
Сам я бекендщик, сужу со своей колокольни. Спросили «почему плохо?» — ответил еще в первом комментарии.
как ниже вот отписал dgstudio мне даже нечего добавить — манипуляция с данными для серьезных приложений это наиболее важный слой.
И наиболее часто подвергается изменениям из требований бизнеса.
Все это в SPA засунуть с кучей промежуточных слоев, бэкенда, частично порезанного, пусть даже api (теряем всю силу бэкенда если он дает нормальный v-слой) потом архитектура фронтенда… И React еще в рамках view держится. А взгляните на Ember и иже с ними ангуляры.
Да, это способ разработки.
Да, это работает и создаются такие проекты.
Нет, это не окончательный вид интернета или не супер-панацея, мода и серебряная пуля.
p.s. кстати есть финт, может в php/laravel так же можно. Создавать не объект AR а просто объект PHP. Изначально не вязанный к БД (poro — Plain Old Ruby Object) и уже потом результаты его работы (работы с копиями такого обьекта) писать в БД
в рельс можно наткнуться на такую проблему но несколько в иных контекстах. Там AR не сильно обвешивает сам класс оберточный методами какие бы выполняли «лишние» запросы но при джойнах так или иначе может выйти похожая ситуация…
Пока что справляюсь силами ORM что и автору советую как то искать способ средствами ORM оптимизировать запросы или убрать лишние. Почти всегда такое удавалось.
p.s. Согласен что мне просто может не попадались серьезные задачи на 1000к запросов с 10 жойнами. Как-то избегал архитектурно )
Имхо, только человекомодерация спасет. И то это огромная головная боль, позволить себе ее могут не все ресурсы. Там будут и тролли через прокси, и ддос, и еще много чего интересного.
но согласитесь, при всех допущениях — "довольно долго" != "всегда". Получается на пороховой бочке точнее в дырявой лодке юзеры окажутся. Вода прибывает и прибывает. Как-то так. С трекерами так же было — до полных блокировок что-то где-то выстреливало, блокировалось, но стоило заняться серьезно — и вот уже скажем хозяин литмира получает уголовное дело.
Мы уважаем Ваш выбор фронтенда как основы.
Но, такой подход не всем подходит.
А слишком черно-бело смотреть на это (или это хорошо, или плохо) я не могу. Промежуточные градации тоже должны быть.
Сам я бекендщик, сужу со своей колокольни. Спросили «почему плохо?» — ответил еще в первом комментарии.
И наиболее часто подвергается изменениям из требований бизнеса.
Все это в SPA засунуть с кучей промежуточных слоев, бэкенда, частично порезанного, пусть даже api (теряем всю силу бэкенда если он дает нормальный v-слой) потом архитектура фронтенда… И React еще в рамках view держится. А взгляните на Ember и иже с ними ангуляры.
Да, это способ разработки.
Да, это работает и создаются такие проекты.
Нет, это не окончательный вид интернета или не супер-панацея, мода и серебряная пуля.
Но статья отличнейшая! Автору спасибо.
Пока что справляюсь силами ORM что и автору советую как то искать способ средствами ORM оптимизировать запросы или убрать лишние. Почти всегда такое удавалось.
p.s. Согласен что мне просто может не попадались серьезные задачи на 1000к запросов с 10 жойнами. Как-то избегал архитектурно )
Или автор про сам паттерн активной записи в общем смысле?
Но вот верно ли только держаться… С другой стороны а что мы еще можем.