За последние 5 лет я работал с различными бессерверными технологиями, создавая API, интеграцию IoT, конвейеры приема данных и многое другое. Однако сегодня я хочу поделиться с вами тем, как мы разработали наш способ создания удобной среды разработки, которую мы используем для многих наших клиентов, больших и малых. Вы обнаружите, что это не только экономит время на разработку, быстрее выводит вас на рынок, но также снижает ваши счета за AWS и делает ваш сайт более масштабируемым. Это серия статей, состоящая из нескольких частей, и она начнется сухо, поскольку мы сосредоточены на создании всего, что вам нужно для создания масштабируемой и гибкой среды.

О чем именно мы говорим? Ну, Serverless Framework, AWS, Express.js, Prisma, OpenAPI и GraphQL (среди некоторых других вкусностей, смешанных тут и там).

Обзор

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

Бессерверная платформа

Serverless Framework — одна из крупнейших платформ для бессерверной разработки на AWS, интегрированная таким образом, что использование CloudFormation встроено в платформу и связано с ускорением графика разработки, обеспечивая как гибкость, так и повторяемость.

Экспресс.JS

Express.JS — это быстрый, бескомпромиссный, минималистичный веб-фреймворк для Node.js, который очень хорошо документирован и чрезвычайно рад новичкам, начинающим писать бэкенды в node.js на основе модели промежуточного программного обеспечения подключения.

Призма

Prisma — это ORM, работающая с PostgreSQL, MySQL, SQL Server, SQLite и MongoDB. Он быстро стал одним из лучших ORM на рынке благодаря простоте использования и множеству функций, которые значительно облегчают разработку!

Открытый API

Спецификация OpenAPI позволяет нам написать документ спецификации, который документирует нашу спецификацию, что позволяет нам легко делиться документацией, создавать клиентов и имитировать наши API с помощью инструментов в своей экосистеме. Лично я большой поклонник создания своих спецификаций с помощью Stoplight.io.

GraphQL

Мы все знаем, что GraphQL отлично подходит для фронтенд-разработки, однако исторически он был ужасной болью для бэкэнд-разработки. Ближе к концу этой серии мы будем использовать typegraphql с primsa, чтобы показать вам безболезненное выполнение, по сути, построение всего вашего бэкенда на основе схемы prisma путем украшения вашей схемы правилами.

Начиная

Теперь, когда мы понимаем основных игроков в игре, давайте сначала заглянем в голову и начнем создавать основу нашего приложения. Эта область довольно категорична в отношении определенных методов разработки, но она делает все более плавным для команды, двигающейся вперед. На данный момент мы предполагаем, что у вас установлен node.js (надеюсь, через nvm) и вы используете node.js v16.

Создание бессерверного проекта

Если у вас еще не установлено serverless, сделайте это сейчас npm install -g serverless или yarn global add serverless. Как только это будет установлено, чтобы начать наш новый проект, мы собираемся следовать руководству, введя serverless, который создаст проект в подкаталоге.

~/Projects ❯ serverless
Creating a new serverless project
? What do you want to make? (Use arrow keys)
❯ AWS - Node.js - Starter
  AWS - Node.js - HTTP API
  AWS - Node.js - Scheduled Task
  AWS - Node.js - SQS Worker
  AWS - Node.js - Express API
  AWS - Node.js - Express API with DynamoDB
  AWS - Python - Starter
  AWS - Python - HTTP API
  AWS - Python - Scheduled Task
  AWS - Python - SQS Worker
  AWS - Python - Flask API
  AWS - Python - Flask API with DynamoDB
  Other
? What do you want to call this project? frictionless-serverless
✔ Project successfully created in frictionless-serverless folder
? What org do you want to add this service to? [Skip]
? Do you want to deploy now? (Y/n) n
What next?
Run these commands in the project directory:
serverless deploy    Deploy changes
serverless info      View deployed endpoints and resources
serverless invoke    Invoke deployed functions
serverless --help    Discover more commands

Теперь мы можем cd войти в наш проект и начать использовать Serverless Framework. Тем не менее, нам нужно немного поработать, прежде чем мы начнем соединять все вместе.

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

Во-первых, давайте cd frictionless-framework и ls каталог, мы видим, что здесь есть несколько файлов. Все файлы, за исключением файла serverless.yml, не имеют значения, вы можете оставить README.md, если хотите, но к концу этой статьи вы, вероятно, захотите переделать его, чтобы ваша команда понимала, что происходит под капюшоны.

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

Настройка среды разработки

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

  • husky — который подключается к git, чтобы наши обработчики коммитов вызывали наши различные программы.
  • lint-staged — который берет наши подготовленные файлы и проверяет их на соответствие нашим программам.
  • commitlint — который проверяет, что наши сообщения коммита непротиворечивы, т.е. (fix|chore|feat): message
  • красивее — что гарантирует согласованность стиля кода
  • eslint — который гарантирует, что мы следуем различным правилам

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

Давайте установим их, не так ли?

yarn init
# answer questions
yarn add -D @commitlint/cli @commitlint/config-conventional eslint eslint-config-prettier husky lint-staged prettier pretty-quick

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

.eslintrc.yml

Здесь мы сообщаем системе, что она расширяется красивее и что мы используем узел и последнюю версию ECMAScript. При необходимости вы можете определить другие правила внутри rules:parameter (мы часто отклоняем любые команды console.*, поскольку это означает, что вы должны предоставлять отзывы пользователей или записывать их во внутреннюю систему отслеживания ошибок.

env:
  browser: false
  commonjs: true
  es2021: true
  node: true
extends:
  - prettier
parserOptions:
  ecmaVersion: latest

.prettierignore

Единственное, что мы действительно хотим игнорировать, — это код, который исходил не от нас, в противном случае все остальное — честная игра.

node_modules/

.lintstagerc

В большинстве случаев нас не волнует переформатирование уцененных документов и т. д. Но нас волнуют файлы JavaScript, не стесняйтесь добавлять дополнительные файлы по своему усмотрению.

'*.js':
  - 'prettier --write'
  - 'eslint'

.commitlintrc.yml

Нам всем нужны определенные сообщения коммитов, формат соглашения означает, что вы добавляете к своим коммитам префикс:

(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test): message

Это полезно, чтобы помочь людям, которые просто фиксируют сообщения, такие как «wip», что не имеет значения, особенно когда вы пытаетесь git bisect

extends:
  - '@commitlint/config-conventional'

Хаски

Husky — наш бегун, Husky обрабатывает наши хуки коммитов и гарантирует, что эти вещи работают при коммите.

yarn husky install
yarn husky add .husky/pre-commit 'yarn lint-staged'
yarn husky add .husky/commit-msg 'npx --no -- commitlint --edit $1'

Теперь мы просто хотим убедиться, что в нашем package.json у нас теперь есть настройка части scripts prepare следующим образом, чтобы гарантировать, что после установки yarn или npm этот husky был инициализирован для запуска наших команд перед фиксацией.

{
  "scripts": {
    "prepare": "husky install"
}

Что теперь?

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

Что ж, фильтр commit-msg выдаст ошибку, не позволив нам совершить фиксацию, если мы не будем следовать формату, и между prettier и eslint он будет гарантировать, что наш стиль кода согласуется со всеми остальными, независимо от того, как мы написали код, чтобы обеспечить рекомендации по стилю. Это означает, что проверка кода будет НАМНОГО меньше о том, сколько пробелов/табуляций или точек с запятой вы использовали, и о том, как вы спроектировали приложение. Сообщение о коммите поможет нам определить при просмотре истории git, что могло повлиять на проект, когда мы делим его пополам на наличие ошибки.

Следующие шаги

После этой статьи мы начнем обсуждать запуск нашей CI/CD, чтобы у нас был простой способ развертывания и управления нашей бессерверной установкой в ​​будущем, поскольку мы продолжаем добавлять дополнительные функции, которые необходимы.