Я начинаю с настройки для моего портфолио. У меня есть несколько целей:

  • Я хочу создать облачное приложение, не зависящее от доставки.
  • Я начну с веб-доставки для целей тестирования, но я разработаю ее таким образом, чтобы в будущем ее было легко распространить на настольные или мобильные устройства.
  • Я не хочу использовать свой личный ноутбук для среды разработки

Когда мы используем наши личные ноутбуки для разработки, это может привести к нескольким проблемам. Во-первых, нашим ноутбукам может не хватать мощности или памяти для выполнения задач по разработке, что может замедлить нашу работу и вызвать разочарование. Это связано с тем, что работа по разработке часто требует большой вычислительной мощности и дискового пространства для бесперебойной работы. Наши персональные ноутбуки могут не иметь тех же мер безопасности, что и выделенная среда разработки.

Приложение может одновременно быть независимым от доставки и облачным. Эти понятия не исключают друг друга и могут дополнять друг друга.

Приложение, не зависящее от доставки, ориентировано на независимость от платформы и переносимость, что позволяет развертывать его в разных средах без серьезных изменений. Он абстрагируется от базовой инфраструктуры и использует стандартизированные интерфейсы и конфигурации.

С другой стороны, облачное приложение специально разработано для запуска и использования облачной инфраструктуры и служб. Он включает в себя облачные принципы, такие как архитектура микросервисов, контейнеризация, масштабируемость и гибкость.

При создании облачного приложения, которое также не зависит от доставки, я стремлюсь спроектировать и разработать приложение таким образом, чтобы его можно было легко развернуть на разных платформах, включая общедоступные облака, частные облака или локальные среды. Некоторые соображения для достижения этой комбинации включают в себя:

  1. Контейнеризация обеспечивает согласованное развертывание и выполнение в различных средах.
  2. Инфраструктура как код позволяет определить желаемое состояние инфраструктуры, делая ее легко воспроизводимой и переносимой на различные облачные платформы.
  3. Абстракция облачных служб позволяет избежать прямых зависимостей от облачных служб или API-интерфейсов в коде моего приложения. Вместо этого я буду использовать слои или фреймворки абстракции, которые обеспечивают согласованный интерфейс для взаимодействия с различными облачными сервисами.
  4. Возможность настройки с помощью внешних файлов конфигурации или переменных среды позволяет настраивать поведение приложения без изменения кодовой базы.

Сочетая принципы облачной разработки с дизайном, не зависящим от доставки, я смогу создавать приложения, оптимизированные для облачной инфраструктуры и способные работать на различных платформах. Этот подход обеспечивает гибкость, масштабируемость и возможность использовать собственные облачные функции, а также обеспечивает переносимость и простоту развертывания в различных средах.

Поскольку я единственный разработчик, работающий над этим проектом, я решил использовать JavaScript как для фронтенда, так и для бэкенда.

Использование одного и того же языка в стеке обеспечит согласованность стиля кодирования, синтаксиса и шаблонов. Мне не нужно было бы переключаться между разными языками и контекстами, что упростило бы понимание и поддержку моей кодовой базы. При использовании JavaScript как для внешнего, так и для внутреннего интерфейса я также могу отлаживать все приложение, используя единый набор инструментов и методов отладки.

Имея все это в виду, я решил использовать AWS CodeStar. Это полностью управляемый сервис, который помогает разрабатывать, создавать и развертывать приложения на AWS.

В следующем посте я поделюсь своими успехами в настройке.

Поскольку я пытаюсь следовать TDD и BDD, я уже начал думать о некоторых дегенеративных тестовых примерах:

Сценарий 1: получение цен, когда услуга недоступна

Given the price retrieval application is running
And the price retrieval service is not available
When a request is made to retrieve prices
Then the application should respond with an error message indicating service unavailability

Сценарий 2. Получение цен с пустым списком товаров

Given the price retrieval application is running
And the product list is empty
When a request is made to retrieve prices
Then the application should respond with an empty result

Сценарий 3. Получение цен с недопустимым названием продукта

Given the price retrieval application is running
And the product list contains valid products
When a request is made to retrieve prices with an invalid product name
Then the application should respond with an error message indicating an invalid product name

Следите за обновлениями!