Концепция API-Only подхода для заказных фич

На докладе одного из продуктов линейки Астры руководитель разработки поделился интересной особенностью подхода к разработке. Начал он с того, что в основе у них лежит тактика API-First.

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

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

Однако, для этих функций так и не появилось (и не планирует появляться) ни одной кнопочки в веб-интерфейсе. Просто потому, что совместно с заказчиками и партнерами пришли к заключению — вызывать их только через API ок.

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

  1. Не надо тратить ресурс дизайнера для продумывания UI/UX функции;
  2. Не надо тратить ресурс Front-разработчика;
  3. Не надо тратить ресурс ручного тестировщика и включать функционал в Sanity-тесты фронта;
  4. Не надо тратить ресурс отдела знаний для составления документации, видеокурсов по интерфейсному использованию. Технари API-описание от технарей и так поймут.

А что вы думаете про такой подход к разработке специфичного функционала? Делали такое в своих продуктах? Или быть может считаете, что если есть функция на бэке — она обязана быть на фронте?

#продукты #продукт #продакт #дизайн #функции #фичи #апи #api #мысли #размышления

Концепция API-Only подхода для заказных фич | Сетка — социальная сеть от hh.ru