Вот мои два цента за лучшую практику среди ваших решений:
При разработке продуктов swagger или пасека являются отличными инструментами для документирования вашего API и быстрого макета API перед их реализацией. С фиктивным API и документацией в руках (скажем, менеджера по продукту) становится легко начать с твердого плана развития. Но такие инструменты, как swagger, могут автоматически макетировать спецификацию API, и если вы хотите импортировать эту спецификацию только для симуляции API, то эта функция импорта - отличный инструмент для использования, в противном случае это не так. Позвольте мне объяснить, почему.
Импортируя API и организуя ресурсы AWS непосредственно из Swagger, вы вводите множество ограничений, основным из которых является процесс разработки, который не включает в себя такую среду, как serverless или zappa. Это заставит нас напрямую писать лямбда-функции, используя консоль AWS или AWS cli, и усложнит архитектуру проекта.
При написании лямбда-функций без каркаса, если мы заранее знаем, что наши функции будут ортогональны друг другу и не имеют общих общих зависимостей, то здорово, что это будет работать, но для любого проекта с (скажем) базой данных, функции, обращающиеся к внешнему API, некоторые конечные точки которых охраняются авторизатором и имеют другие ресурсы, использование инфраструктуры, безусловно, является лучшим вариантом. Легче создавать слои и общий код, например, класс оболочки базы данных.
При использовании любого фреймворка лучше начинать с эталонного образца фреймворка и делать реализацию, соответствующую документации. Изучив преимущества и ограничения этой платформы, мы можем решить, соответствует ли она нашей архитектуре.
Кроме того, ИМО, этот метод не используется широко, и в дальнейшем поиск помощи может оказаться затруднительным, поскольку проект становится более сложным.
надеюсь, это поможет.