Как мне подружить DRF и ASW Cognito?
Планирую делать проэкт на serverless (AWS lambda) DRF + Vue. Посмотрел, что у AWS есть Cognito, захотелось его прикрутить. Но у меня несколько вопросов уже в голове.
- Фронт логин делает через DRF? Или сам идет на Cognito, а потом передает токен в DRF? Какой вариант и чем лучше?
- Для DRF (Django) есть хорошие пакеты или лучше юзать boto3 и через клиет делать?
- Если я захочу сделать двух-факторную авторизацию, но не хочу использовать ASW SNS для доставки СМС, могу я к Cognito прикрутить Twillio?
Ну и общий вопрос по Django ASW lamdba. Планирую делать через zappa. Имеет ли вообще такой подход право на жизнь? Будет много проблем? И я так понял, что zappa загортает все в одну ламбду, а API Gateway все проксит на джанго аппку, тогда если пойти на несуществующий урл, API Gateway пропустит реквест в аапку, а апка вернет 404, но ламбда запустится, и буде жрать денги. Если так, то как с этим боротся?
Как-то много вопросов получилось, ну может что-то и узнаю нового.
Иван Шумов
@inoise Куратор тега Amazon Web Services
Solution Architect, AWS Certified, Serverless
Много букв, но!
По Serverless:
- никакого Django ибо в lambda сразу приезжает request, а роутинг делается на api gateway. это функциональное программирование считай
- посмотри на Serverless Framework
- boto3 классная вещь, но не забывай что это просто обертка к сервисам
- zappa в помойку, она ничего на самом деле не умеет, а деплоит все бесконтрольно в твой аккаунт
- проблемы будут если тебе нужно низкое latency ибо lambda имеет холодный старт (можно снизить через новую фичу)
- 404 в API Gateway делается как ANY /{proxy+} -> lambda
По Cognito:
- выкинуть. Если нет готовности тратить дни и недели на то чтобы получить хоть что-то
- погляди на Auth0
Как раз хочу Django и запихнуть в lambda, поэтому не буду выкидывать его.
zappa в помойку
А чем тогда готовить lambd-у? Мне не нужно супер-пупер много, просто потестировать.
проблемы будут если тебе нужно низкое latency
Вообще не проблема, само-собой было понятно, что нужно время на запуск
404 в API Gateway делается как ANY /{proxy+} -> lambda
Не совсем понял. То есть так и будет, если пойти на неверный урл (напр /polls/asasa), то API gateway пропустит его на Django аппликацию, апликация приймет его, но отдаст 404 респонс. Но деньги возьмет за время работы lambda? Меня интересует как не пускать такие реквесты, приписивать какие-то конфиги в API Gateway (на подобие как в nGinx)?
Написано
Иван Шумов
@inoise Куратор тега Amazon Web Services
Как раз хочу Django и запихнуть в lambda, поэтому не буду выкидывать его.
Ни одна из основных фич джанго не понадобится в lambda по тому что она stateless, а роутинг обеспечивается api gateway. Все остальное можно докидать пакетами
А чем тогда готовить lambd-у? Мне не нужно супер-пупер много, просто потестировать.
я уже дал ссылку на serverless framework. Это максимально easy
Меня интересует как не пускать такие реквесты, приписивать какие-то конфиги в API Gateway (на подобие как в nGinx)?
никак. В API GW нет такого функционала
Еще добавлю что если использовать Django то lambda станет бесполезным решением по тому что она станет запускаться ОЧЕНЬ медленно и соответственно встанет ОЧЕНЬ дорого
Написано
Иван Шумов
@inoise Куратор тега Amazon Web Services
Yura Khlyan, Вообще Lambda рассчитана что в одной функции будет кодовая база для одной операции. Если ставить туда монолит то виртуалки резко становятся удобнее и дешевле.
Не говоря уже о том что Django никогда не получит изначальный реквест от пользователя по тому что в lambda это абсолютно другой объект из другого места
Простой
Простой
