Комментарии 9
> До недавнего времени разработка бессерверных приложений сильно осложнялась тем, что не было средств полноценного локального тестирования lambda-функций и API. При создании приложений нужно было или работать все время онлайн, редактируя код в браузере, или постоянно архивировать и загружать в облако исходный код lambda-функций.
По крайней мере для AWS lambda-функция на Python, можно всегда поставить на свой комп boto3 и спокойно отлаживать лямбду в любимом PyCharm.
По крайней мере для AWS lambda-функция на Python, можно всегда поставить на свой комп boto3 и спокойно отлаживать лямбду в любимом PyCharm.
+2
НЛО прилетело и опубликовало эту надпись здесь
Переменные, объявленные вне вызова функции handler, при повторных вызовах обычно не инициализируются повторно. То есть соединение с БД не будет каждый раз устанавливаться заново, если функция вызывается достаточно часто. Lambda сохраняет контейнер функции в «горячем» состоянии. Вот интересный пост на эту тему: https://www.jeremydaly.com/reuse-database-connections-aws-lambda/.
Разворачивать инфраструктуру я предполагаю командами aws cli на основе шаблона CloudFormation + bash код. Подобный скрипт я приводил в своей предыдущей статье про то, как мы делаем AB-DOC.
Насчет zappa и WSGI — не знал. Почитал сейчас. Во-первых, я никогда не программировал на Python (может зря). Во-вторых, мне априори не нравятся сторонние фреймворки, не поддерживаемые вендором. Они могут быстро становится ненужными и лишаться поддержки, если сам вендор предложит полноценное решение. А SAM и sam-local похоже всерьез и надолго.
Последнее предложение вашего комментария я не в силах до конца понять.
Разворачивать инфраструктуру я предполагаю командами aws cli на основе шаблона CloudFormation + bash код. Подобный скрипт я приводил в своей предыдущей статье про то, как мы делаем AB-DOC.
Насчет zappa и WSGI — не знал. Почитал сейчас. Во-первых, я никогда не программировал на Python (может зря). Во-вторых, мне априори не нравятся сторонние фреймворки, не поддерживаемые вендором. Они могут быстро становится ненужными и лишаться поддержки, если сам вендор предложит полноценное решение. А SAM и sam-local похоже всерьез и надолго.
Последнее предложение вашего комментария я не в силах до конца понять.
0
Интересно, но смущает несколько моментов:
— непонятно зачем свой велосипед на фроненде. Вроде бы vue как раз и позиционируется как достаточно простой фреймворк. На это же уйдёт достаточно много времени в будущем.
— действительно, реляционная БД вряд ли будет хорошо работать с функциями
— нужно переименовывать проект, если есть расчёт на популярность в open source. Ab-erp — вообще не понятно, что это прямой конкурент Serverless.
То, что получается напоминает Google Firebase. Вы его пробовали? Там и хостинг статики есть, и авторизации из коробки, и функции. И много чего ещё (например, аналитика). Можно локально разрабатывать. Плюс, SDK для мобильных на всякий случай.
— непонятно зачем свой велосипед на фроненде. Вроде бы vue как раз и позиционируется как достаточно простой фреймворк. На это же уйдёт достаточно много времени в будущем.
— действительно, реляционная БД вряд ли будет хорошо работать с функциями
— нужно переименовывать проект, если есть расчёт на популярность в open source. Ab-erp — вообще не понятно, что это прямой конкурент Serverless.
То, что получается напоминает Google Firebase. Вы его пробовали? Там и хостинг статики есть, и авторизации из коробки, и функции. И много чего ещё (например, аналитика). Можно локально разрабатывать. Плюс, SDK для мобильных на всякий случай.
0
1. Насчет Vue.js — согласен, отличный фреймворк. Но вы смотрите на вопрос, как программист. Да, Vue.js может здорово повысить продуктивность написания кода для некоторых типов приложений. Но сколько программистов знают Vue.js и сколько знают jQuery? На сколько больше нужно платить программистам Vue.js? В общем это не столь однозначный вопрос. И я больше склоняюсь к тому, что нам не нужен фреймворк, если взвешивать все за и против и оценивать пользу фреймворка для конкретного типа приложений. Наши приложения — это ERP-системы, которые состоят в основном из форм и таблиц.
2. По-моему с этим все ОК, написал выше.
3. Мы вовсе не делаем конкурента Serverless framework. Скорее можно сказать, что Serverless framework и sam-local конкуренты, но никак не AB-ERP. А название AB-ERP выбрано из-за того, что наша заготовка в первую очередь ориентирована на создание ERP-систем и тому подобных приложений.
Google Firebase — это конкурент AWS. Не берусь сравнивать их с AWS, с Firebase я не работал. Много лет назад «подсел» на AWS и с тех пор не перестаю восхищаться ими, это целая вселенная :) Мне кажется, в целом они опережают своих конкурентов на годы. Об этом красноречиво говорят шильдики «бета» напротив многих сервисов Firebase.
2. По-моему с этим все ОК, написал выше.
3. Мы вовсе не делаем конкурента Serverless framework. Скорее можно сказать, что Serverless framework и sam-local конкуренты, но никак не AB-ERP. А название AB-ERP выбрано из-за того, что наша заготовка в первую очередь ориентирована на создание ERP-систем и тому подобных приложений.
Google Firebase — это конкурент AWS. Не берусь сравнивать их с AWS, с Firebase я не работал. Много лет назад «подсел» на AWS и с тех пор не перестаю восхищаться ими, это целая вселенная :) Мне кажется, в целом они опережают своих конкурентов на годы. Об этом красноречиво говорят шильдики «бета» напротив многих сервисов Firebase.
0
Так есть уже и Claudia.js и Serverless.js. Там вроде не сложно всё.
По поводу тестирования, serverless.js с пол пинка заводится на карме и для локальной разработке есть serverless-offline(добавьте туда что захочется, типо локальной MySQL или DynamoDB, S3 тоже локально работает).
По поводу тестирования, serverless.js с пол пинка заводится на карме и для локальной разработке есть serverless-offline(добавьте туда что захочется, типо локальной MySQL или DynamoDB, S3 тоже локально работает).
0
Пишу сугубо свое мнение, могу ошибаться. Я считаю, что эти проекты — следствие того, что AWS вовремя не создал адекватные средства для удобной разработки бессерверных приложений. Люди не хотели ждать, и это понятно, поэтому появились эти проекты. По своей сути, это «костыли» или временные решения. Автор плагина serverless-offline уже объявил о своем нежелании продолжать проект и просит кого-то его подхватить. В общем будущее за SAM и sam-local, именно на этих технологиях стоит выстраивать процесс разработки в долгосрочной перспективе.
Упс. Промахнулся. Отвечал zaikin-andrew.
Упс. Промахнулся. Отвечал zaikin-andrew.
0
Шаблоны SAM трансформируются CloudFront в обычные шаблоны при деплое.Здесь скорее всего имелось ввиду CloudFormation, а не CloudFront
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Фреймворк для бессерверных приложений в AWS