Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
Я тот самый девопс )).
Из текста не очень ясно, я так понимаю, что у вас весь бэкенд находится в mongo? А где тогда хоститься клиент?
Я тут небольшую програмку писал, но я выбрал google firebase. Но у меня конечно всё маленькое получилось — пара таблиц и с десяток функций.
Честно сказать serverless замечательная вещь, жаль что не везде можно использовать.
Из текста не очень ясно, я так понимаю, что у вас весь бэкенд находится в mongo? А где тогда хоститься клиент?
Я тут небольшую програмку писал, но я выбрал google firebase. Но у меня конечно всё маленькое получилось — пара таблиц и с десяток функций.
Честно сказать serverless замечательная вещь, жаль что не везде можно использовать.
Какая проблема раздать клиента из s3 клаудфронтом?
В самом простом случае (если не нужен SSR) у Mongo.Atlas есть встроенный хостинг статики с поддержкой CDN. В нашем случае пришлось немножко поизголяться и взять виртуалку у Google Cloud и CDN у G-core.
Firebase для средних и больших проектов крайне не советую — периодически безбожно тупит и иногда вылетает. Для 99.9 точно не подойдёт.
Интересное решение, но, как то боязно, конкуренты организуют лёгкий DDOS и все, продавай квартиру, просто повышенный интерес пользователей (я так понимаю именно поэтому не приведена ссылка на ресурс) — хабраэффект — плати, я понимаю зачем такой подход облачным провайдерам, но владельцу ресурса выгода только на стадии роста посещаемости, этакий MVP, пока неизвестно взлетит/не взлетит. Толстый мобильный фронтенд так себе решение, не так много пользователей обладают мощными устройствами за 1000$, чтобы с комфортом пользоваться ресурсом. В общем с технической стороны решение интересное, а с практической так себе. Возможно я не прав, буду рад выслушать контраргументы.
Вот именно ради таких комментариев я и написал эту статью, спасибо большое!
Да риски есть, я об этом тоже размышлял, но думаю от DDOS эффективнее защищаться другими способами. У того же GCore есть сервис для отсеивания атак и на сетевом и на прикладном уровнях. Из «плюсов» Mongo, то что computed-runtime рассчитывается месячными лимитами, и в худшем случае конкурент положит нам бэк, до тех пор пока мы не разбермся, что происходит, при этом пользователи будут по прежнему получать готовые страницы из кэша. Правда данные какое-то время не будут актуализироваться, поскольку лягут все триггеры синхронизации с внешними API и мы не сможем наполнять контент. Но для нашей модели в пределах суток-двух это не критично, потому что информация о будущих событиях собирается заранее на несколько дней вперед, дополняется описанием авторов и попадает в кэш в виде готовых страниц.
На сейчас я исхожу из следующих соображений:
1) Размер пока такой, что конкурентам не интересно тратиться на DDOS
2) Если размер станет большой, взаимодействие с Mongo.Realm перетащим от клиента в промежуточный бэк и повесим защиты от DDOS
3) Если все-таки кто-то начнет мочить до этих мероприятий, то цена потерь не велика, в худшем случае пару дней данные будут не самые актуальные, но при этом для поисковиков и для клиентов мы будем выглядеть условно живыми.
Но это в теории, проверять не хочется пока, поэтому и ссылку не стал давать.
Про толщину мобильного клиента, он развесистый, но не настолько чтобы не работать на устройствах за 100$. Единственная проблема, что на мобилах первая полная загрузка занимает до 5-10 секунд, но сервис предполагает большой ретеншен, так что второй раз все возьмется из кэша.
Да риски есть, я об этом тоже размышлял, но думаю от DDOS эффективнее защищаться другими способами. У того же GCore есть сервис для отсеивания атак и на сетевом и на прикладном уровнях. Из «плюсов» Mongo, то что computed-runtime рассчитывается месячными лимитами, и в худшем случае конкурент положит нам бэк, до тех пор пока мы не разбермся, что происходит, при этом пользователи будут по прежнему получать готовые страницы из кэша. Правда данные какое-то время не будут актуализироваться, поскольку лягут все триггеры синхронизации с внешними API и мы не сможем наполнять контент. Но для нашей модели в пределах суток-двух это не критично, потому что информация о будущих событиях собирается заранее на несколько дней вперед, дополняется описанием авторов и попадает в кэш в виде готовых страниц.
На сейчас я исхожу из следующих соображений:
1) Размер пока такой, что конкурентам не интересно тратиться на DDOS
2) Если размер станет большой, взаимодействие с Mongo.Realm перетащим от клиента в промежуточный бэк и повесим защиты от DDOS
3) Если все-таки кто-то начнет мочить до этих мероприятий, то цена потерь не велика, в худшем случае пару дней данные будут не самые актуальные, но при этом для поисковиков и для клиентов мы будем выглядеть условно живыми.
Но это в теории, проверять не хочется пока, поэтому и ссылку не стал давать.
Про толщину мобильного клиента, он развесистый, но не настолько чтобы не работать на устройствах за 100$. Единственная проблема, что на мобилах первая полная загрузка занимает до 5-10 секунд, но сервис предполагает большой ретеншен, так что второй раз все возьмется из кэша.
Оно работает ровно до тех пор пока это MVP, а как посещаемость начнёт расти нужно будет всё переделывать. Вообщем скупой платит дважды, но это не проблема если это учитывалось изначально, ведь количество свободных денег тоже должно вырасти.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Serverless и полтора программиста