Serverless и полтора программиста

[de1m]

Я тот самый девопс )).
Из текста не очень ясно, я так понимаю, что у вас весь бэкенд находится в mongo? А где тогда хоститься клиент?
Я тут небольшую програмку писал, но я выбрал google firebase. Но у меня конечно всё маленькое получилось — пара таблиц и с десяток функций.

Честно сказать serverless замечательная вещь, жаль что не везде можно использовать.

[hellamps]

Какая проблема раздать клиента из s3 клаудфронтом?

[RuslanGabbasov]

В самом простом случае (если не нужен SSR) у Mongo.Atlas есть встроенный хостинг статики с поддержкой CDN. В нашем случае пришлось немножко поизголяться и взять виртуалку у Google Cloud и CDN у G-core.

[ertaquo]

Firebase для средних и больших проектов крайне не советую — периодически безбожно тупит и иногда вылетает. Для 99.9 точно не подойдёт.

[RuslanGabbasov]

И еще один серьезный минус в историях с Firebase — в момент, когда появляется более-менее внеямый объем запросов, ценник становится заоблачным. У монги в этом отношении пока все намного лучше.

[uldashev]

Интересное решение, но, как то боязно, конкуренты организуют лёгкий DDOS и все, продавай квартиру, просто повышенный интерес пользователей (я так понимаю именно поэтому не приведена ссылка на ресурс) — хабраэффект — плати, я понимаю зачем такой подход облачным провайдерам, но владельцу ресурса выгода только на стадии роста посещаемости, этакий MVP, пока неизвестно взлетит/не взлетит. Толстый мобильный фронтенд так себе решение, не так много пользователей обладают мощными устройствами за 1000$, чтобы с комфортом пользоваться ресурсом. В общем с технической стороны решение интересное, а с практической так себе. Возможно я не прав, буду рад выслушать контраргументы.

[RuslanGabbasov]

Вот именно ради таких комментариев я и написал эту статью, спасибо большое!

Да риски есть, я об этом тоже размышлял, но думаю от DDOS эффективнее защищаться другими способами. У того же GCore есть сервис для отсеивания атак и на сетевом и на прикладном уровнях. Из «плюсов» Mongo, то что computed-runtime рассчитывается месячными лимитами, и в худшем случае конкурент положит нам бэк, до тех пор пока мы не разбермся, что происходит, при этом пользователи будут по прежнему получать готовые страницы из кэша. Правда данные какое-то время не будут актуализироваться, поскольку лягут все триггеры синхронизации с внешними API и мы не сможем наполнять контент. Но для нашей модели в пределах суток-двух это не критично, потому что информация о будущих событиях собирается заранее на несколько дней вперед, дополняется описанием авторов и попадает в кэш в виде готовых страниц.

На сейчас я исхожу из следующих соображений:
1) Размер пока такой, что конкурентам не интересно тратиться на DDOS
2) Если размер станет большой, взаимодействие с Mongo.Realm перетащим от клиента в промежуточный бэк и повесим защиты от DDOS
3) Если все-таки кто-то начнет мочить до этих мероприятий, то цена потерь не велика, в худшем случае пару дней данные будут не самые актуальные, но при этом для поисковиков и для клиентов мы будем выглядеть условно живыми.

Но это в теории, проверять не хочется пока, поэтому и ссылку не стал давать.

Про толщину мобильного клиента, он развесистый, но не настолько чтобы не работать на устройствах за 100$. Единственная проблема, что на мобилах первая полная загрузка занимает до 5-10 секунд, но сервис предполагает большой ретеншен, так что второй раз все возьмется из кэша.

[jetcar]

Оно работает ровно до тех пор пока это MVP, а как посещаемость начнёт расти нужно будет всё переделывать. Вообщем скупой платит дважды, но это не проблема если это учитывалось изначально, ведь количество свободных денег тоже должно вырасти.

[RuslanGabbasov]

Все так, все так! Но гипотезы надо проверять как можно быстрее и дешевле. И я изначально старался проектировать так, чтобы этот переход был не очень больным и дорогим.