Тут я полностью согласен, что представление об архитектуре шире и имеет кучу аспектов.
А это определение скорее является упрощением для подчеркивания контраста между разными уровнями, где FSD это потенциальное решение лишь определенной части вопросов и проблем. То есть отношение к архитектуре в конечном итоге оно конечно имеет и это упоминается несколько раз, просто говорится о том, что в итоге это все же не архитектура в полном смысле.
В конце концов, полный академический разбор всех этих аспектов заслуживает отдельной статьи, здесь не совсем про это. Но возможно было бы уместно это упомянуть.
Да, вы правы, с «все начинается одинаково» конечно преувеличение)
Далее я упоминаю, что FSD действительно затрагивает архитектурные вопросы, но лишь частично. И там нет критики FSD за то, что она не решает то, что по определению не собирается решать. Мысль в этом и есть, что не нужно обманываться, будто внедрив FSD все станет круто, у каждого инструмента своя область применения и надо смотреть на архитектуру шире.
Как раз посыл посыл в том, что FSD даже при идеальном использовании не сделает проект поддерживаемым, для этого нужно заниматься еще кучей других вопросов
Все верно, это мой недочет, потому что по ходу написания я в этом месте пару раз менял пример и забыл поменять оператор на правильный :) будет исправлено, спасибо!
У нас платформа для проведения соревнований и очень часто взвешивание участников проходит в каком-то подвале с плохим интернетом. И именно для такого кейса это крайне актуально, у них просто не успевают многие тяжелые запросы выполниться до конца, когда они уже решают поменять страницу.
То что прерванный запрос мог бы пригодиться на другой странице для нас слишком edge кейс пока что) Но замечание хорошее, кому-то это стоит учитывать.
Звучало такое предложение, как раз из-за влияния Firebase на перформанс) но пока решили, что трудозатраты перехода того не стоят...
У нас вся инфраструктура находится в облаке, в котором есть свои сервисы, и в том числе авторизация с Firebase. У Firebase много готовых решений как на беке, так и на фронте, работает очень стабильно и не требует разворачивания сторонних сервисов (которые нужно либо хостать у себя, либо разворачивать инстанс за оплату в месяц)
Даже с tree-shaking? У нас из-за Vuetify тоже много чего лишнего есть, но мы выбрали стратегию использовать его по минимуму - только для функциональных компонентов (селекты, модалки и тд), а визуальные пишем сами.
Это, в том числе, облегчило миграцию проекта с Vue 2 на 3, тк пришлось проходить через меньшее количество breaking changes у Vuetify 3, а также закладывает почву для того, чтобы однажды вообще отказаться от Vuetify
Справляемся за счет того, что у нас есть собственный SSR, но это отдельная большая тема)
С Nuxt был не очень веселый опыт раньше, когда мы решили SPA на него переписать (какие-то либы отваливались, интеграция с firebase вроде еще в бете была), но сейчас думаю мы к этому больше готовы и в принципе присматриваемся к Nuxt 3
Такой проблемой не занимались. А про картинки да, возможно стоило добавить в статье, что у нас используется CDN сервис (imagekit), который автоматически конвертирует изображения в webp и еще позволяет загружать изображения только нужного размера
Вы никак не меняли FSD под себя?
Тут я полностью согласен, что представление об архитектуре шире и имеет кучу аспектов.
А это определение скорее является упрощением для подчеркивания контраста между разными уровнями, где FSD это потенциальное решение лишь определенной части вопросов и проблем. То есть отношение к архитектуре в конечном итоге оно конечно имеет и это упоминается несколько раз, просто говорится о том, что в итоге это все же не архитектура в полном смысле.
В конце концов, полный академический разбор всех этих аспектов заслуживает отдельной статьи, здесь не совсем про это. Но возможно было бы уместно это упомянуть.
Да, вы правы, с «все начинается одинаково» конечно преувеличение)
Далее я упоминаю, что FSD действительно затрагивает архитектурные вопросы, но лишь частично. И там нет критики FSD за то, что она не решает то, что по определению не собирается решать. Мысль в этом и есть, что не нужно обманываться, будто внедрив FSD все станет круто, у каждого инструмента своя область применения и надо смотреть на архитектуру шире.
Относятся конечно, но повторюсь, что все это не архитектура
И речь идет именно про FSD, потому что от нее ожидают большего, чем оно есть на самом деле
Как раз посыл посыл в том, что FSD даже при идеальном использовании не сделает проект поддерживаемым, для этого нужно заниматься еще кучей других вопросов
Все верно, это мой недочет, потому что по ходу написания я в этом месте пару раз менял пример и забыл поменять оператор на правильный :) будет исправлено, спасибо!
Я полагаю, что тогда можно добавить такую проверку; остальное остается актуальным
да, запросы должны отмениться
У нас платформа для проведения соревнований и очень часто взвешивание участников проходит в каком-то подвале с плохим интернетом. И именно для такого кейса это крайне актуально, у них просто не успевают многие тяжелые запросы выполниться до конца, когда они уже решают поменять страницу.
То что прерванный запрос мог бы пригодиться на другой странице для нас слишком edge кейс пока что) Но замечание хорошее, кому-то это стоит учитывать.
Есть какие-то предложения?
Звучало такое предложение, как раз из-за влияния Firebase на перформанс) но пока решили, что трудозатраты перехода того не стоят...
У нас вся инфраструктура находится в облаке, в котором есть свои сервисы, и в том числе авторизация с Firebase. У Firebase много готовых решений как на беке, так и на фронте, работает очень стабильно и не требует разворачивания сторонних сервисов (которые нужно либо хостать у себя, либо разворачивать инстанс за оплату в месяц)
Даже с tree-shaking? У нас из-за Vuetify тоже много чего лишнего есть, но мы выбрали стратегию использовать его по минимуму - только для функциональных компонентов (селекты, модалки и тд), а визуальные пишем сами.
Это, в том числе, облегчило миграцию проекта с Vue 2 на 3, тк пришлось проходить через меньшее количество breaking changes у Vuetify 3, а также закладывает почву для того, чтобы однажды вообще отказаться от Vuetify
Справляемся за счет того, что у нас есть собственный SSR, но это отдельная большая тема)
С Nuxt был не очень веселый опыт раньше, когда мы решили SPA на него переписать (какие-то либы отваливались, интеграция с firebase вроде еще в бете была), но сейчас думаю мы к этому больше готовы и в принципе присматриваемся к Nuxt 3
Спасибо за дополнение, в каких-то случаях это действительно можно учитывать
Обычно заказчик смотрит, взлетает ли идея, а уже в зависимости от этого принимается решение, хоронить проект или развивать дальше.
Спасибо!
Такой проблемой не занимались. А про картинки да, возможно стоило добавить в статье, что у нас используется CDN сервис (imagekit), который автоматически конвертирует изображения в webp и еще позволяет загружать изображения только нужного размера