Результат работы SSR можно положить в кеш и уже оттуда отдавать клиентам. Отдав первую страницу мы сократим время отображения пустой страницы, в основной массе клиентов это будет не заметно. а вот при медленном интернете это может иногда может помочь не потерять пользователя. Последующий запросы уже будут генерироваться на стороне пользователя
Каким способом рендерить контент, каждый может выбрать для себя сам, с учетом потребностей и возможностей. SSR закрывает основные требования для отображения страницы, при этом проект находится в относительно едином стиле
Сервер рендерит контент и кладет его в кеш. Да, клиенты бывают разные и некоторые могут превосходить по мощности сервер, но так же есть устройства менее производительные. Используя SSR можно быть уверенным что таким способом первая страница отобразиться быстрее. Последующие запросы с клиента уже будут рендериться на стороне клиента.
Vue хороший и удобный фреймворк для фронта который может закрыть основную массу потребностей. Что бы не плодить лишние библиотеки и поддерживать между ними связи, проще все таки использовать SSR
Когда появляется флажок на задаче, то исполнителя назначают на того разработчика, который ее делал. По этому если даже разработчик отфильтрует задачи по себе, он увидит эафлагованную задачу.
Мы специально не вносили дополнительных статусов в воронку, для прозрачности этапов которые прошла задача. Визуально задача находится на том месте, где появился блокер. Так же не стоит забывать про small win, разработчику комфортнее видеть на доске задачу которая ближе к завершению))
Приоритет у задачи с флажками справа на лево и сверху вниз. У задачи в UAT, шансов доехать до релиза выше, чем у задачи которая в QA. По этому если появляется по флажку в этих колонках, нужно первым делать править флажок в UAT, затем в QA и только потом возвращаться к задаче которая в работе.
Если вернется одна задача из QA и еще одна из UAT - нет гарантии, что их, переведя обратно, расположат в приоритетном порядке. А для того что бы посмотреть из какой воронки задача вернулась - нужно заходить в каждую задачу. Так же если разработчиков несколько - Продакту и Тимлиду понятнее в каком статусе задача при одном взгляде на доску.
Ситуация в которой беклог больше, чем команда может обработать встречается у больших и маленьких команд. Это реалии бизнеса, в которых важно наладить внутренние процессы и ранжировать входящие запросы. Таким образом правильно налаженный процесс позволяет снизить техдолг, распределить нагрузку и работать с запросами, которые не влияют напрямую на метрику и соответственно оценить их важность сложно.
Спасибо вам за комментарий. Согласны, что наше решение может выглядеть очевидным. Тем не менее с такой проблемой сталкивается большинство команд. Каждая отдельная команда имеет свои особенности и существует в своем контексте, все это ведет к тому, что известные и "давно обкатанные" методы могут потребовать адаптации для конкретной команды. Мы решили поделиться нашим опытом, надеемся, что он кому-нибудь пригодится и тогда мы будем рады, что наш кейс и статья полезны.
Если нет необходимости распределять контент по регионам, и есть возможность обслуживать свой сервер, вероятно эта опция может подойти.
Мы нашли для себя более удобное решение, которое удовлетворяет нас с точки зрения производительности, отказоустойчивости, стоимости обслуживания и эксплуатации. В данном случае косты почти нулевые, помимо платы за трафик.
Если представить ситуацию, что трафик равномерен и ходит к нам с одной частотой, то расчеты верные. Однако не учтен тот факт, что большинство запросов даже в этом случае будут идти на одни и те же статические файлы. Тогда возникает риск упереться в производительность не только сетевого канала.
Вместе с тем нагрузка со временем все равно возрастает. Так же CDN это все таки не только про ширину канала, но и про распределенность статического контента, чтобы он был как можно ближе к потребителю + отказоусточивость.
Все верно, если брать неделю как чистое время одного специалиста. В действительности над задачей работали несколько специалистов, и, если говорить о чистом времени реализации, то с тестами это оказалось чуть выше 40 часов.
Если взять текущий ваш расчет, то даже с учетом такой окупаемости это выгодно в перспективе. Поскольку нагрузка в 50GB в сутки не фиксированная, а постоянно растет. На момент когда мы принимали решение о запуске такой задачи в работу, наши траты составляли 400$ в месяц. Если бы жили с предыдущим решением дальше, то траты возросли бы >600$ в месяц.
Vue фреймворк который закрывает основные потребности. Как раз для того, что бы не использовать другие решения можно использовать SSR
Результат работы SSR можно положить в кеш и уже оттуда отдавать клиентам. Отдав первую страницу мы сократим время отображения пустой страницы, в основной массе клиентов это будет не заметно. а вот при медленном интернете это может иногда может помочь не потерять пользователя. Последующий запросы уже будут генерироваться на стороне пользователя
Каким способом рендерить контент, каждый может выбрать для себя сам, с учетом потребностей и возможностей. SSR закрывает основные требования для отображения страницы, при этом проект находится в относительно едином стиле
Сервер рендерит контент и кладет его в кеш. Да, клиенты бывают разные и некоторые могут превосходить по мощности сервер, но так же есть устройства менее производительные. Используя SSR можно быть уверенным что таким способом первая страница отобразиться быстрее. Последующие запросы с клиента уже будут рендериться на стороне клиента.
Vue хороший и удобный фреймворк для фронта который может закрыть основную массу потребностей. Что бы не плодить лишние библиотеки и поддерживать между ними связи, проще все таки использовать SSR
Мы предлагаем, прежде всего, руководствоваться здравым смыслом и рендерить на фронте то, что допустимо в конкретном кейсе.
Когда появляется флажок на задаче, то исполнителя назначают на того разработчика, который ее делал. По этому если даже разработчик отфильтрует задачи по себе, он увидит эафлагованную задачу.
Мы специально не вносили дополнительных статусов в воронку, для прозрачности этапов которые прошла задача. Визуально задача находится на том месте, где появился блокер. Так же не стоит забывать про small win, разработчику комфортнее видеть на доске задачу которая ближе к завершению))
Приоритет у задачи с флажками справа на лево и сверху вниз. У задачи в UAT, шансов доехать до релиза выше, чем у задачи которая в QA. По этому если появляется по флажку в этих колонках, нужно первым делать править флажок в UAT, затем в QA и только потом возвращаться к задаче которая в работе.
Если вернется одна задача из QA и еще одна из UAT - нет гарантии, что их, переведя обратно, расположат в приоритетном порядке. А для того что бы посмотреть из какой воронки задача вернулась - нужно заходить в каждую задачу. Так же если разработчиков несколько - Продакту и Тимлиду понятнее в каком статусе задача при одном взгляде на доску.
Ситуация в которой беклог больше, чем команда может обработать встречается у больших и маленьких команд. Это реалии бизнеса, в которых важно наладить внутренние процессы и ранжировать входящие запросы. Таким образом правильно налаженный процесс позволяет снизить техдолг, распределить нагрузку и работать с запросами, которые не влияют напрямую на метрику и соответственно оценить их важность сложно.
Спасибо вам за комментарий. Согласны, что наше решение может выглядеть очевидным. Тем не менее с такой проблемой сталкивается большинство команд. Каждая отдельная команда имеет свои особенности и существует в своем контексте, все это ведет к тому, что известные и "давно обкатанные" методы могут потребовать адаптации для конкретной команды. Мы решили поделиться нашим опытом, надеемся, что он кому-нибудь пригодится и тогда мы будем рады, что наш кейс и статья полезны.
Если нет необходимости распределять контент по регионам, и есть возможность обслуживать свой сервер, вероятно эта опция может подойти.
Мы нашли для себя более удобное решение, которое удовлетворяет нас с точки зрения производительности, отказоустойчивости, стоимости обслуживания и эксплуатации. В данном случае косты почти нулевые, помимо платы за трафик.
Если представить ситуацию, что трафик равномерен и ходит к нам с одной частотой, то расчеты верные. Однако не учтен тот факт, что большинство запросов даже в этом случае будут идти на одни и те же статические файлы. Тогда возникает риск упереться в производительность не только сетевого канала.
Вместе с тем нагрузка со временем все равно возрастает. Так же CDN это все таки не только про ширину канала, но и про распределенность статического контента, чтобы он был как можно ближе к потребителю + отказоусточивость.
Все верно, если брать неделю как чистое время одного специалиста. В действительности над задачей работали несколько специалистов, и, если говорить о чистом времени реализации, то с тестами это оказалось чуть выше 40 часов.
Если взять текущий ваш расчет, то даже с учетом такой окупаемости это выгодно в перспективе. Поскольку нагрузка в 50GB в сутки не фиксированная, а постоянно растет. На момент когда мы принимали решение о запуске такой задачи в работу, наши траты составляли 400$ в месяц. Если бы жили с предыдущим решением дальше, то траты возросли бы >600$ в месяц.