Дизајн со API на прво место: зошто е важен пред да помислите дека ви треба

Кога еден SaaS производ е мал, искушението е да се изгради наједноставното нешто што работи: веб-апликација тесно врзана за својата база на податоци, со деловна логика распослана низ контролери и фронтенд. Се испорачува побрзо. Полесно е за разбирање во раните денови.

Потоа производот расте. Клиент сака интеграција со својот ERP систем. Партнер сака да го продава производот под свој бренд. Потребни се мобилни апликации. Втор производ треба да ги дели истите кориснички податоци.

Одеднаш архитектурата што беше едноставна станува препрека меѓу бизнисот и неговата следна фаза на раст.

Што всушност значи „API на прво место“

„API на прво место“ не значи да изградите јавен API уште првиот ден. Значи да го дизајнирате системот така што целата функционалност е достапна преку добро дефиниран интерфејс — таков што вашиот сопствен фронтенд го користи, точно како што би го користел кој било надворешен клиент.

Веб-апликацијата станува клиент. Мобилната апликација станува клиент. Интеграцијата од трета страна станува клиент. Сите разговараат со истиот основен API.

Дисциплината што ја наметнува ова е поентата. Кога вашиот сопствен тим не може да си скратува пат со директни прашања до базата од фронтендот, деловната логика живее на едно место, се спроведува доследно и може да се проширува без несакани последици.

Деловниот аргумент

Интеграциите стануваат тривијални. Клиент што сака да ги внесе вашите податоци во Salesforce или да ги извлече од својот систем за управување со магацин не бара посебен инженерски проект. Го користи истиот API што го користи сѐ друго. Работата е конфигурација, а не изградба.

Продажбата под туѓ бренд станува можна. Ако вашата архитектура ја одвојува производната логика од презентацискиот слој, може да се изгради различен фронтенд за друг бренд без дуплирање на основниот систем. Тоа отклучува цела категорија партнерски договори што инаку би биле невозможни.

Мобилното не е дополнителна мисла. Производите што не биле дизајнирани со API на прво место обично се мачат да изградат квалитетни мобилни апликации. Податоците се заплеткани во HTML генериран на серверот, деловната логика се прелева во шаблоните за приказ, а мобилниот тим троши повеќе време разоткривајќи го бекендот отколку градејќи го производот.

Воведувањето станува функционалност на производот. Кога клиентите можат да го автоматизираат своето воведување и увоз на податоци преку вашиот API, побрзо го усвојуваат производот и поретко се откажуваат. Добро документиран API е алатка за задржување.

Честиот приговор

„Ќе го преработиме кога ќе ни затреба.“

Проблемот со овој план е што додека да ви затреба, производот е во продукција, клиентите зависат од него, а преработката на архитектурата е шестмесечен проект што се натпреварува со секое барање за функционалност и секоја поправка на грешка. Тимовите што ветуваат преработка подоцна речиси никогаш не стигнуваат до неа.

Цената на дизајн со API на прво место однапред е скромна — неколку дополнителни дена планирање, јасно одвојување на одговорностите од самиот старт. Цената на дополнително вградување API во тесно врзан код е огромна, а ризикот од расипување на продукцијата е реален.

Практична почетна точка

Не ви требаат GraphQL, gRPC или архитектура со микросервиси уште првиот ден. Добро структуриран REST API со доследно именување на ресурсите, соодветна автентикација, јасно верзионирање од v1 и промислени одговори при грешка е доволен за темелот што ви е потребен.

Клучните прашања на кои треба да одговорите пред да ја напишете првата рута:

• Кои се основните ресурси во овој систем?
• Кои операции ги поддржува секој ресурс?
• Како ќе функционираат автентикацијата и авторизацијата за внатрешни и надворешни корисници?
• Како ќе се соопштуваат и верзионираат измените што кршат компатибилност?

Ако ги погодите овие на почетокот, чини речиси ништо. Ако ги промашите, чини сѐ што сте заштедиле.

---

PNK WORKS проектира и гради SaaS производи дизајнирани да растат — почнувајќи од слојот со API. Започнете проект.