Я кодирую лямбды AWS последние три года. Каждый новый проект начинается с мысли: «На этот раз код будет написан очень хорошо». И каждый раз по прошествии нескольких месяцев проект становится слишком большим, чтобы соответствовать ограничениям, о которых я не знал. Либо это язык, над которым я работаю (ES5 JS), либо через какое-то время появляется что-то новое, из-за чего мой старый код выглядит чушью, или даже некоторые действительно странные ограничения. Например, сколько инструкций можно разместить в одном файле AWS CloudFormation.

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

serverless create --template-url https://github.com/rallu/kyllikki/tree/master/template --path myproject

Это небольшой шаг вперед по сравнению с предоставленным Serverless шаблоном aws-nodejs-typescript. Что он тогда добавляет? Просто небольшая библиотека @kyllikki/core , предназначенная для четкого написания конечных точек API с помощью Typescript.

Что же тогда делает Килликки?

Вот типичный класс, который обрабатывает вызовы API. GET, POST, PUT, DELETE, PATCH и ANY можно импортировать из основного пакета и добавить в качестве декоратора для функции, которую вы хотите запустить. Формат пути такой же, как в вашем файле serverless.yml.

Как видите, я предпочитаю, чтобы имена функций были очень информативными. Это также полезно, поскольку Kyllikki может использовать эти имена функций в качестве идентификаторов в своем модуле OpenAPI.

И вот что вам нужно добавить в код обработчика:

С такой архитектурой вы можете решить, какие конечные точки будут запускаться этим обработчиком. Это важно для разделения или объединения файлов журналов и трассировщиков в инфраструктуре AWS. В этом примере все конечные точки Cat API работают в одном обработчике.

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

Расширенные возможности

Двумя другими основными функциями Kyllikki являются проверка ввода и обработка ошибок.

Kyllikki использует joi -библиотеку для проверок. Валидации передаются в конфигурацию опций декоратора. В этом примере мы убеждаемся, что тело содержит JSON с обязательным атрибутом имени. Если эта проверка не удалась, выдается сообщение об ошибке 400.

Другие варианты проверки - это параметры пути, заголовки и параметры строки запроса.

Kyllikki по умолчанию перехватывает ошибки и отправляет обратно ошибку HTTP 400, но это можно настроить с помощью параметра ошибок. Здесь вы определяете ожидаемые ошибки и какой HTTP-код следует отправлять. Также есть способ написать собственную функцию для обработки ошибки. Для этого проверьте страницу GitHub.

Больше возможностей!

Первоначальная причина, по которой я написал эту библиотеку, заключалась в том, что я хотел иметь возможность выводить конфигурацию OpenApi V3 из моего кода. И это по-прежнему конечная цель. Хотя я решил отделить его от основных функций Kyllikki в отдельном пакете. @kyllikki/openapi пакет как раз по этой причине. Потому что основы Kyllikki хороши для использования в любом из моих будущих проектов, а openapi еще нет.

Пакет Openapi все еще находится в разработке. Меня не устраивает текущий метод, когда разработчику нужно написать полную схему JSON для документирования API.

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