Я думаю нормализация оценок по сотрудникам это самообман. Обычно задачки на оценку 360 людям приходят с периодичность раз в пару месяцев и, выбранная в прошлый раз шкала, в голове не сохраняется. Сегодня устал и все задолбали: шкала нормальных оценок от 2 до 4, настало лето и хорошее настроение всем от 4 до 5. Да и вообще мерять с помощью балльной системы по 360 это явно от большой менеджерской лени, единственный способ вскрыть проблемы и реально оценить эффективность оцениваемого можно если не лениться и каждый раз создавать новый набор открытых вопросов, а затем читать и думать. Объективности 360 реально добавляет мало, но зато дает возможность для адекватной субъективной оценки.
Все так, все так! Но гипотезы надо проверять как можно быстрее и дешевле. И я изначально старался проектировать так, чтобы этот переход был не очень больным и дорогим.
Вот именно ради таких комментариев я и написал эту статью, спасибо большое!
Да риски есть, я об этом тоже размышлял, но думаю от DDOS эффективнее защищаться другими способами. У того же GCore есть сервис для отсеивания атак и на сетевом и на прикладном уровнях. Из «плюсов» Mongo, то что computed-runtime рассчитывается месячными лимитами, и в худшем случае конкурент положит нам бэк, до тех пор пока мы не разбермся, что происходит, при этом пользователи будут по прежнему получать готовые страницы из кэша. Правда данные какое-то время не будут актуализироваться, поскольку лягут все триггеры синхронизации с внешними API и мы не сможем наполнять контент. Но для нашей модели в пределах суток-двух это не критично, потому что информация о будущих событиях собирается заранее на несколько дней вперед, дополняется описанием авторов и попадает в кэш в виде готовых страниц.
На сейчас я исхожу из следующих соображений:
1) Размер пока такой, что конкурентам не интересно тратиться на DDOS
2) Если размер станет большой, взаимодействие с Mongo.Realm перетащим от клиента в промежуточный бэк и повесим защиты от DDOS
3) Если все-таки кто-то начнет мочить до этих мероприятий, то цена потерь не велика, в худшем случае пару дней данные будут не самые актуальные, но при этом для поисковиков и для клиентов мы будем выглядеть условно живыми.
Но это в теории, проверять не хочется пока, поэтому и ссылку не стал давать.
Про толщину мобильного клиента, он развесистый, но не настолько чтобы не работать на устройствах за 100$. Единственная проблема, что на мобилах первая полная загрузка занимает до 5-10 секунд, но сервис предполагает большой ретеншен, так что второй раз все возьмется из кэша.
И еще один серьезный минус в историях с Firebase — в момент, когда появляется более-менее внеямый объем запросов, ценник становится заоблачным. У монги в этом отношении пока все намного лучше.
В самом простом случае (если не нужен SSR) у Mongo.Atlas есть встроенный хостинг статики с поддержкой CDN. В нашем случае пришлось немножко поизголяться и взять виртуалку у Google Cloud и CDN у G-core.
Да риски есть, я об этом тоже размышлял, но думаю от DDOS эффективнее защищаться другими способами. У того же GCore есть сервис для отсеивания атак и на сетевом и на прикладном уровнях. Из «плюсов» Mongo, то что computed-runtime рассчитывается месячными лимитами, и в худшем случае конкурент положит нам бэк, до тех пор пока мы не разбермся, что происходит, при этом пользователи будут по прежнему получать готовые страницы из кэша. Правда данные какое-то время не будут актуализироваться, поскольку лягут все триггеры синхронизации с внешними API и мы не сможем наполнять контент. Но для нашей модели в пределах суток-двух это не критично, потому что информация о будущих событиях собирается заранее на несколько дней вперед, дополняется описанием авторов и попадает в кэш в виде готовых страниц.
На сейчас я исхожу из следующих соображений:
1) Размер пока такой, что конкурентам не интересно тратиться на DDOS
2) Если размер станет большой, взаимодействие с Mongo.Realm перетащим от клиента в промежуточный бэк и повесим защиты от DDOS
3) Если все-таки кто-то начнет мочить до этих мероприятий, то цена потерь не велика, в худшем случае пару дней данные будут не самые актуальные, но при этом для поисковиков и для клиентов мы будем выглядеть условно живыми.
Но это в теории, проверять не хочется пока, поэтому и ссылку не стал давать.
Про толщину мобильного клиента, он развесистый, но не настолько чтобы не работать на устройствах за 100$. Единственная проблема, что на мобилах первая полная загрузка занимает до 5-10 секунд, но сервис предполагает большой ретеншен, так что второй раз все возьмется из кэша.