Мы тут слепили API на AWS Lambda PaaS. В-общем пора помечтать о "второй версии". Идея сделать некий opinionated framework, в который некий галерный раб (т.е. не второй я) будет копипастой вписывать новые интеграции. И "общую" часть, не содержащую специфики нашего сервиса, выложить на гитхаб.
Проблема в том, что сейчас оно тоже копипастой, но сделано так, что чудовищный объём клея по сравнению с объёмом смыслового кода. Хочется, чтобы была неизменная "рыба", в которую только смысловой код вписывать, и чтобы было максимально негибко, но в то же время можно было "фреймворк" выкинуть и сделать "по-старому".
Также хочется по максимуму задействовать инструментальную поддержку всяческую:
- IDEA и VsCode
- Postman
- OpenAPI Schema Validation
- AWS-сервисы типа X-Ray (но там реально ~десяток наберётся)
Притом надо сделать так, чтобы в "умный" код никто не лез. Т.е. писать для людей, для которых простыни на 700 строк это "просто", а заменяющие их 7 строк - это "зачем так сложно, когда можно просто..". Бить их так сказать их же подходом "Оно же работает? не трожь!". А если вдруг не работает -- то вот херачь к хуям и копипасть отсюда "простой" вариант, а дальше его своими методами доводи напильником, а потом как-нибудь я это увижу и переделаю фреймворк как надо, чтобы новый код в него вписался.
Кроме этого базовые вещи внедрить:
- CD - уже внедрён просто по техническим причинам (в PaaS напрямую не зальёшь, а если лить скриптом с машины разраба - то просто медленно ибо инет хуёвый, а нормального нет по техпричинам; поэтому деплоит всегда Гитлаб, просто вот совсем-совсем всегда, если на прод).
- CI нет из-за отсутствия тестов, которых в свою очередь нет, так как код работает в PaaS и в-основном занимается перекладыванием данных из одного апи в другой, включая ~5 SaaS от AWS. То есть нужно мокать достаточно много всего, для чего надо показать, как мокать, чтобы можно было действовать "по образцу". Ну а если не мокать то надо делать дизайн не как выйдет, а такой, чтобы можно было хотя бы что-то проверять по типу "вход-выход", т.е. "без инета" и без моков.
- Тестовый эндпоинт и тестовые планы для подключающихся. Это в принципе можно сделать через JSON Schemas, просто дав очень детальную схему того, какие варианты ответов возможны.
- Валидацию и типы по метаданным, а не простыни if request.foo == bar then throw Error. Благо API у нас высокостабильный, т.е. логично использовать в коде доку как the only source of truth, а не из кода доку лепить.
- К вопросу о доке - вcё обмазать JsDoc в формате, подстроенном под использование в IDE
- метрики, алерты и уровни логирования
- Нормальные аутентификации в ассортименте. Понятно, что всё это может быть как 4 схемы, так и 1, поддерживающая все фичи сразу. Хочется:
- Более стандартную схему, эквивалентную тому, что делается сейчас в API v1 (request body HMAC+nonce; у нас там ещё чуть хуже, по образцу того что сделано у конкурентов)
- труЪ схему с non-repudiation. Есть UK OpenBanking, там всё энтерпрайзно. Есть FAPI 1, там какие-то говно и палки в стиле OpenId/OAuth, есть вроде FAPI2 с non-repudiation, но это во-первых драфты, во-вторых там чёрт ногу сломит в спеке, как-то непонятно даже мне, долго прокуривать надо
- какую-то схему, которая хорошо поддерживается в Postman
- какую-то схему, под которую у всех давно есть либы
- сегментацию приложения в соответствии с духом рекомендаций PCI DSS. Мы-то технически можем хоть сервисную пыль сделать, но во-первых влетит в копеечку, во-вторых если везде заборы - то затрудняется работа; надо выработать какой-то компромисс и заложить его во фреймворк
По схемам хочется валидировать не только себя, но и пиров - т.е. валидировать всё (можно статистически, т.е. семплировать изредка):
- HTTP Requests от клиентов к нам
- HTTP Responses от нас к клиентам
- HTTP Requests от нас к партнёрам
- HTTP Responses от партнёров к нам
