Dlaczego aplikacje API-first mogą zyskać przewagę?

Jak sugeruje nazwa, API-first design to podejście charakteryzujące się naciskiem na programistyczny interfejs aplikacji. Mowa tutaj nie tylko o API budowanym wewnętrznie, ale także o tym dostępnym dla technicznych użytkowników czy nawet całych organizacji. Nietrudno się domyślić, że taka strategia mocno przekłada się nie tylko na sam development, ale cały proces rozwoju produktu. Choć sama koncepcja jest znana od lat, to wiele wskazuje na to, że jej czas dopiero nadchodzi, i w tym wydaniu odpowiem na pytanie — dlaczego API-first może stanowić przewagę w Świecie nowoczesnych aplikacji oraz AI?

O co chodzi z API?

Aby mieć pewność, że jest to jasne — API (eng. Application Programming Interface) to sposób komunikacji z aplikacją w sposób programistyczny z pomocą kodu czy narzędzi no-code. Konkretnie mówimy tutaj o zapytaniach HTTP na adresy projektowane, chociażby w oparciu o zasady REST. Możemy wykorzystywać je zarówno wewnętrznie (internal API), jak i zewnętrznie (external API).
Zatem wizualny, graficzny interfejs użytkownika, w tym przypadku nie jest konieczny. Z drugiej strony, nierzadko to właśnie front-end wykorzystuje API, umożliwiając komunikację z back-endem. Co więcej, sam back-end również może korzystać API do komunikacji z zewnętrznymi usługami, np. w celu wysyłania maili transakcyjnych czy obsługi płatności. Oznacza to mniej więcej tyle, że API jest, lub może być, praktycznie wszędzie.

I chociaż wykorzystanie wewnętrznego API w architekturze aplikacji, można obecnie uznać za powszechne, tak już projektowanie takiego interfejsu dostępnego dla użytkowników, jest nadal bardzo rzadkie. A to otwiera wiele, interesujących możliwości, które zauważają już także największe fundusze VC i nawet można spotkać się z określeniami "API-first Economy".
Z praktycznego punktu widzenia, API to zwykle zestaw funkcji wystawionych jako adresy URL, na które możemy przesyłać żądania i otrzymywać odpowiedzi. Ich zaprojektowanie w sposób spójny, użyteczny, wydajny i bezpieczny wcale nie jest takie oczywiste. Tym bardziej, że złożoność aplikacji zwykle rośnie, a gdy z naszego API korzystają użytkownicy lub nawet całe platformy, konieczne jest zapewnienie wsparcia i wprowadzanie tzw. "non-breaking changes" w celu utrzymania stabilności ich rozwiązań.

Jakie możliwości oferuje publiczne API?

Graficzny interfejs wymaga od użytkownika stałego zaangażowania w obsługę aplikacji. W najlepszym przypadku mówimy jeszcze o możliwości zaplanowania akcji według harmonogramu lub w odpowiedzi na jakieś zdarzenie. Niezależnie od scenariusza, mówimy o korzystaniu z aplikacji w sposób zdefiniowany przez ludzi tworzących dane oprogramowanie. Choć z jednej wiąże się to z dużą wygodą, tak jednocześnie do gry wchodzą spore ograniczenia i niemal brak potencjału na optymalizację oraz skuteczne połączenie z innymi usługami.
Jeszcze kilka lat temu, nie odgrywało to aż tak istotnej roli, ponieważ z API korzystały wyłącznie osoby techniczne. Oznacza to, że co najwyżej brak API zamykał nas na zewnętrzne integracje i opcję dołączenia do istniejących ekosystemów, co już samo w sobie może być bardzo dużą stratą.
Obecnie sytuacja wygląda zupełnie inaczej, ponieważ obecność narzędzi no-code, takich jak Zapier czy Make.com, pozwala na korzystanie z API także osobom, które nie potrafią programować. Naturalnie poszerza to grono odbiorców aplikacji, co ma przełożenie nie tylko na sam biznes, ale także sam rozwój produktu. Dobrze zaprojektowany feedback-loop, pozwala na jego skuteczny rozwój, zgodnie z oczekiwaniami rynku.
W tym wszystkim nie chodzi jedynie o samą bazę użytkowników, ale także o możliwe zastosowania, w połączeniu z innymi aplikacjami oraz usługami. Niezależnie od tego, czy mówimy tutaj o zastosowaniu no-code czy programistycznych integracjach, chodzi o automatyzację lub znaczną optymalizację procesów biznesowych. Poniżej mamy przykład takiego zastosowania, łączącego szereg różnych usług w celu automatyzacji procesu publikowania podcastu. Dzięki temu, nie mam potrzeby logować się do tych wszystkich usług, ponieważ dane przepływają pomiędzy nimi w sposób automatyczny. Ja jedynie otrzymuję powiadomienie o zrealizowanym zadaniu, bądź zapytania o potwierdzenia publikacji.

Choć wygląda to imponująco i faktycznie coraz więcej narzędzi zaczyna dostrzegać istotę budowania sensownego API wraz z dokumentacją, tak na przestrzeni ostatniego roku, sytuacja zaczęła rozwijać się jeszcze bardziej dynamicznie. Główną rolę odgrywa tutaj ... Sztuczna Inteligencja, która zmienia zasady gry, lub przynajmniej przenosi powyższe zastosowania na zupełnie nowy poziom.

API jako narzędzie, którym posługuje się AI

W czasie pisania tych słów, jeszcze stosunkowo niewiele osób zdaje sobie sprawę z tego, że API może być wykorzystywane przez duże modele językowe, np. GPT-4, do podejmowania działań. Można to rozumieć jako zupełnie nowy poziom tworzenia integracji czy automatyzacji, ponieważ w tym przypadku mówimy o systemach zdolnych do częściowo autonomicznego realizowania całych procesów. Niewykluczone, że niebawem będziemy mówić o pełnej autonomiczności, ponieważ tempo rozwoju projektów wykorzystujących koncepcję agentów, czy tzw. Artificial Swarm Intelligence, jest imponujące. Niezależnie od rozwoju sytuacji, już teraz znajdujemy się w miejscu, w którym AI jest w stanie dość swobodnie posługiwać się dostarczonymi narzędziami. Z kolei narzędzia te, w wielu przypadkach są niczym innym, jak zapytaniami kierowanymi do API.
Jak to działa w praktyce, pokazywałem już kilka tygodni temu na jednym z moich filmów na YouTube, przygotowanych z okazji szkolenia AI_Devs. Film można zobaczyć tutaj: https://www.youtube.com/watch?v=toI-PYascI0.

Kilka dni temu miała miejsce konferencja DevDay organizowana przez OpenAI, która w zasadzie potwierdziła wszystko to, co widać na filmie powyżej. Różnica jest jednak taka, że skala osób, do których dotarł ten komunikat, jest globalna. Już teraz, z perspektywy tych kilku dni, patrząc na aktywności związane z zaprezentowanymi GPT (własnymi wersjami ChatGPT), które możemy wyposażyć w narzędzia (czyli API), można przypuszczać, że bardzo szybko świadomość roli programistycznego interfejsu znacznie wzrośnie.
Nie jestem pewien, czy wyraźnie widać to, jak AI posługujące się narzędziami może wpłynąć na nasze życie. Przykładowo dziś, jak każdego dnia, mój panel Notion został automatycznie uzupełniony o informację, których dziś będę potrzebował. Zostały one pobrane poprzez API z mojej listy zadań, kalendarzy, źródeł wiedzy, systemów płatności i skrzynek e-mail. Nie mówimy jednak tutaj o wszystkich zbiorczych informacjach, ale tych, które zostały sklasyfikowane, jako istotne. Taki proces ma miejsce codziennie o 5:30 i odbywa się automatycznie.

Jeśli dołożymy do tego fakt, że elementami powyższego panelu mogę sterować poprzez wysłanie wiadomości na Slacku, czy głosowo z poziomu mojego zegarka, to zaczyna robić się interesująco. I choć jeszcze niedawno można to było uznać jako projekt "geeka", który poskładał w całość kilka narzędzi, tak teraz dzięki GPTs mówimy o koncepcjach, które szybko mogą stać się powszechnie dostępne.

Wyspecjalizowane API

Może się wydawać, że na potrzeby automatyzacji czy AI, mówimy o bardzo rozbudowanym API, nierzadko połączonym z konkretnymi platformami, np. Resend czy Stripe. Okazuje się jednak, że jest ogromna przestrzeń na aplikacje, które oferują wyspecjalizowane API do realizowania konkretnych zadań. Dobrym potwierdzeniem moich słów jest obecność platform takich jak RapidAPI, na których można spotkać bardzo dopasowane do określonych zadań aplikacje.

Oczywiście obowiązuje tutaj naturalna zasada tzw. marketplace, czyli realnie spośród tysięcy użytkowników, realnie ~1-3% tworzy rozwiązania z których korzystają inni. Nie oznacza to zatem, że każdy, kto tworzy API, od razu staje się milionerem czy dostaje oferty pracy od najlepszych firm. Ponownie jest to jednak pewnego rodzaju kierunek, który moim zdaniem, zasługuje na naszą uwagę.
Poza tym, API może zostać wykorzystane także w obszarze prywatnym. Oznacza to, że jako programiści i programistki możemy tworzyć rozwiązania, które będą usprawniać naszą codzienność prywatną oraz zawodową. Tutaj mówimy nawet o przykładach aplikacji wystawiających zaledwie jedną, nierzadko prostą funkcję, której rola może być znacząca. Jednym z przykładów w moim przypadku, jest banalnie prosta aplikacja zapisująca przesłany plik na serwerze. Dzięki niej wgrałem już tysiące plików z pomocą jednego skrótu klawiszowego. Również na potrzeby tworzenia tego wpisu, obecne w nim grafiki, są zrzutami ekranu, które natychmiast poddawane są optymalizacji przez tinyPNG API, a następnie trafiają na mój hosting.
Na tej samej zasadzie działa większość najbardziej użytecznych narzędzi z których korzystam. Fakt, że mówimy o małych aplikacjach sprawia, że łatwo jest mi nimi zarządzać. Poza tym, jeśli mówimy o zewnętrznych dostawcach, zmniejsza się w ten sposób ryzyko związane z uzależnieniem od usług na które nie mam wpływu. Dla przykładu API do tłumaczeń (deepl.com) mogę z powodzeniem zastąpić innym. Podobnie wypadają generatory grafik (np. htmlcsstoimage) czy API aplikacji do zadań, kalendarzy, notatek, newsletterów czy newsfeedu.
Nie zmienia to jednak faktu, że z pewnością należy brać pod uwagę ryzyka związane z korzystaniem z zewnętrznych API. Z drugiej strony, nierzadko jest to jedyne rozsądne rozwiązanie, ponieważ koszt związany z opracowaniem własnych narzędzi, mógłby być zwyczajnie zbyt duży.

Umiejętność projektowania API stanie się kluczowa?

Patrząc na to wszystko, wiele wskazuje na to, że projektowanie API, faktycznie może stać się jedną z najważniejszych programistycznych umiejętności. Co więcej, jeśli już teraz potrafisz programować, to masz za sobą prawdopodobnie najważniejszą barierę, a być może nawet mówimy tutaj o pewnego rodzaju przewadze.
Tworzenie API niemal w całości odbywa się na back-endzie. Oznacza to, że potrzebujesz znać technologię działającą po stronie serwera oraz połączyć ją z ogólną wiedzą i dobrymi praktykami rozwoju aplikacji, a także samego API. Co więcej, niemal zawsze do gry wchodzi tutaj wykorzystanie baz danych, np. mySQL, postgreSQL czy MongoDB.
Pomimo tak szerokiego zakresu nowych umiejętności oraz narzędzi koniecznych do budowania własnego API, postawienie pierwszych, wyraźnych kroków w tym obszarze, jest stosunkowo proste. Sytuacja staje się jeszcze prostsza w chwili, gdy pracujesz w ekosystemie JavaScriptu (np. w roli front-end developera czy front-end developerki), ponieważ język ten możesz wykorzystać także po stronie serwera. Więcej na ten temat pisałem w ostatnim wydaniu naszego newslettera: Jeśli znasz JavaScript, znasz backend. Czy na pewno?.
Aplikacje działające po stronie front-endu, momentami stają się niezwykle złożone. Nierzadko mówimy nawet o sytuacjach w których to back-end staje się "lekki", a jego rola sprowadza się jedynie do wystawienia stosunkowo prostego API i zarządzenia bazą danych. W przypadku rozwijanych przeze mnie produktów, raczej mówimy o balansie pomiędzy clientem a serwerem i trudno jednoznacznie stwierdzić, która strona jest bardziej złożona. Bez względu na rozkład ciężaru aplikacji, wyraźnie widać to, jak różne koncepcje przenikają się pomiędzy front-endem i back-endem. Można to wykorzystać na swoją korzyść w procesie nauki, poprzez połączenie posiadanej wiedzy i umiejętności z tym, co czeka nas na back-endzie.
W poprzednim newsletterze pisałem o tym, co zrobić, aby zacząć tworzenie back-endu, co było równoznaczne ze zbudowaniem swojego pierwszego API. Tym razem, moja propozycja polega na dołączeniu do spotkania Jak zrozumieć back-end, pracując na froncie?, które dziś (13.11.2023) o 19:00 poprowadzę wspólnie z Michałem Jabłońskim i które bezpośrednio będzie nawiązywać do zbliżającego się Sprintu Technologicznego na eduweb.pl, skupionego na projektowaniu aplikacji back-endowych oraz API.
Podczas tego live'a, nasza skupi się przede wszystkim na:

• Podobieństwach w zarządzaniu komunikacja i przesyłam danych
• Sposobach zapisywaniu danych po stronie klienta i serwera
• Walidacji danych oraz tym, dlaczego musi być ona obecna na backendzie
• Technikach obsługi błędów i ich roli w komunikacji client/serwer
• Logowaniu informacji przydatnych z perspektywy rozwoju i monitorowania aplikacji

Inaczej mówiąc — jeśli myślisz o rozwoju w kierunku full-stack developmentu, back-end developmentu lub po prostu chcesz dowiedzieć się "co się dzieje po drugiej strony", pracując na froncie, to nie może Cię z nami zabraknąć.

>> Dołącz do mnie i Michała dziś o 19:00 <<

• Internal vs Public API
• API i automatyzacja procesów
• API jako narzędzie dla AI
• Artificial Swarm Intelligence i API-First Economy