Вопрос, к знатокам, как лучше строить структуру, к примеру у меня есть обьект собака, я хочу get, post, delete, update. Я должен создавать 4 отдельные лямбды или одну которая будет обрабатывать в зависимости от запроса?
Во-первых, собака - это не объект.
Во-вторых, за delete собаке в некоторых странах могут привлечь в уголовной ответственности, да и в целом не гуманно.
В-третьих, если предположить, что под собакой вы подразумеваете какую-то базу данных, то на кой вам вообще облачные функции? Вероятнее всего то, что вы хотите - это просто интерфейс, а делать его в облаках - зачем?
Написано
Иван Шумов
@inoise Куратор тега Amazon Web Services
Ivan Yakushenko, ну Ваня, ну начинается) serverless подход нужен когда:
- нет желания платить за простой ресурсов
- хочется иметь горизонтальное масштабирование
- писать минимум кода
- иметь маленькую команду без 100500 тысяч работы девяпсам по администрированию
- latency не является критичным
По базам данных - тут человеку в чистом виде нежно сделать REST API: API GW + Lambda, за которой с высокой вероятностью будет сидеть DynamoDB (ибо опция на этот счет в AWS не очень много)
Иван Шумов, ну так на задачу нужно смотреть, а то из вводных данных только собака. Может выясниться, что там тыщи запросов в минуту, но по ресурсам кроме i/o-bound ничего, в итоге тут и инстанс за 5$ на DO справится, а функции сожрут кошелек.
Написано
Иван Шумов
@inoise Куратор тега Amazon Web Services
Ivan Yakushenko, при равных прочих serverless выйдет дешевле по тому что масштабирование надо делать ручками, делать это хорошо и сверху к этому придется прикручивать довольно много сервисов чтобы получить результат. Так что я почти всегда за этот подход) ну и не забываем что если висе правильно делать то база данных тоже будет отдельным слоем, тоже будем за нее платить и толе поддерживать
Иван Шумов, ты говоришь о комплексных решения, а если просто прослойка между бд и клиентом? Клацаешь десять строк кода, ввинчиваешь в какой-то веб сервер и все работает за 5$ в месяц, вопрос масштабирования практически никогда в таких задачах не стоит, по-этому лучшее решение - это fixed-price и о котором тебе не нужно думать.
Написано
Иван Шумов
@inoise Куратор тега Amazon Web Services
Ivan Yakushenko, чисто теоретически - да. С другой стороны это просто привычка. Я вот из тех людей кто за 12+ лет работы в разработке так и не получил слово деплой. Я дико ненавижу конфигурировать веб-сервер, окружение, забыть какой-нибудь модуль, ... Serverless для меня снял подобные вопросы. Конечно, я лишился некоторых привычных инструментов, как и основного своего языка программирования, но со временем стало пофиг)
Естественно, без этого никуда. Как говорится - кто как хочет, так и делает. У меня подход в этом плане простой - путь наименьшего сопротивления. Привычные инструменты - он самый. Я не против решать задачи со специфическими подходами, когда это требует заказчик, но от привычек убежать тяжело.
Написано
Иван Шумов
@inoise Куратор тега Amazon Web Services
Ivan Yakushenko, Подход вполне разумный, на короткую дистанцию) А я вот стал специально переучиваться
Иван Шумов, так у меня других дистанций сейчас и нет. Не забывай, что мы работает в слишком разных условиях и с разными задачами - ты решаешь проблемы бизнеса, который любит оптимизацию на всех уровнях, from scratch to production, так сказать. Я решаю задачи конкретных заказчиков, которым нужно понятно, просто, что бы работало и где-то сэкономить. Serverless - это не совсем просто и понятно для большинства заказчиков. Так что у меня собака - это собака, а serverless - когда стоит задача, а не потому что это может быть лучше, даже если без "может быть".
Написано
Иван Шумов
@inoise Куратор тега Amazon Web Services
Ivan Yakushenko, согласен, в принципе) хотя и у меня не каждый второй проект нулевый, увы
Во-вторых, за delete собаке в некоторых странах могут привлечь в уголовной ответственности, да и в целом не гуманно.
мясо же
Написано
Решения вопроса 1
Иван Шумов
@inoise Куратор тега Amazon Web Services
Solution Architect, AWS Certified, Serverless
До определенного момента не играет роли. В данном случае причинами делать несколько лямбд может быть:
- увеличение безопасности (разные права у каждой лямбды)
- увеличение перформанса (разные подключаемые модули и разные настройки, включая память)
- разная логика
- поддержка разных версий
- разделенное логирование
Иван Шумов
@inoise Куратор тега Amazon Web Services
Алексей Белов, в некоторых случаях - да, в некоторых ну такое себе. Все зависит от случая. Лично я предпочитаю сделать несколько лямбд и прицепить к ним через npm или lambda layers слой в DDD. В принципе такая история что для API Gateway валидация модели должна происходить в самом API Gateway Model, в исполняемом методе - трансформация и пробросим параметров, а в DDD уже все остальное, но это идеальный случай. Я так привык делать, мне не сложно, но для большинства это дополнительный большой объем работы
Простой
