W tym rozdziale:
Przez lata korzystaliśmy z aplikacji uruchamianych na komputerze, które nie wymagały podłączenia z Internetem. W ten sposób realizowaliśmy bardzo konkretne zadania, mając do dyspozycji wyłącznie funkcje oferowane przez takie aplikacje. W sytuacji gdy zaczynało nas to ograniczać, jedynym sposobem było ręczne przeniesienie danych lub ewentualnie skorzystanie z opcji eksportu i importu danych, co i tak nie zawsze było dostępne.
W momencie gdy Internet stał się dostępny niemal dla wszystkich, pojawiły się opcje synchronizacji danych w chmurze oraz możliwość współpracy jednocześnie nad tymi samymi danymi. Tutaj pierwsze były aplikacje do zarządzania projektami a potem edycja dokumentów (Google Apps). Dziś nawet designerzy są w stanie pracować jednocześnie nad tym samym projektem z pomocą chociażby Figmy. Zatem jasno widać tutaj pewną ścieżkę, prowadzącą nas od sytuacji w której aplikacje działały niezależnie, do punktu w którym przeniosły się do Internetu i wersji przeglądarkowych. To ułatwiło wspólną pracę i dostęp do naszych danych z dowolnego urządzenia.
No i skoro jesteśmy przy urządzeniach, to po drodze przeszliśmy rewolucję związaną z urządzeniami mobilnymi a w zasadzie multiplatformowością. To sprawiło że proces wytwarzania i projektowania oprogramowania bardzo się skomplikował. Teraz programiści nie tylko musieli rozwijać główną wersję aplikacji ale również dbać o ich wersje mobilne na smartfony i tablety. I w ten sposób doszliśmy do strategii projektowania architektury aplikacji wykorzystując API, czyli programistyczny interfejs aplikacji.
Aby zrozumieć czym jest API, należy wiedzieć że "intrefejs" to sposób umożliwiający komunikację. A programistyczny interfejs aplikacji to sposób umożliwiający komunikację w ramach jednej lub wielu aplikacji.
Taka strategia sprawiła że proces tworzenia aplikacji na wiele platform niesamowicie się uprościł, bo programiści nie tworzą wielu wersji aplikacji. W zamian (posługując się uproszczonym schematem) wystarczy jeden serwer udostępniający dane użytkowników, do których mogą podłączać się aplikacje stworzone na konkretne platformy, jednak ich poziom skomplikowania jest w tym przypadku już zdecydowanie mniejszy.
Poza tym do odpowiednio przygotowanego API mają dostęp nie tylko programiści konkretnej aplikacji ale również wszyscy, którzy uzyskają klucze dostępu (np. API key).
<aside> 💡 Dodam tylko że obecnie mamy do dyspozycji technologie takie jak React Native czy Flutter, które umożliwiają stworzenie jednej wersji aplikacji, która uruchamiana jest na wielu platformach. To ponownie upraszcza development i jest korzystne z punktu widzenia biznesowego.
</aside>
To wszystko doprowadziło nas do powstania strategii tworzenia oprogramowania o nazwie "API-First Design". Z perspektywy tego, co właśnie napisałem jest to w pełni uzasadnione. Skoro możemy pisać jeden kod aby obsłużyć wiele platform, to dlaczego mielibyśmy tego nie robić?
I teraz jakie ma to znaczenie dla osób nie będących programistami? Takie, że podejście API-First można wykorzystywać jako strategie prowadzenia biznesu i wykorzystywania aplikacji - dzięki automatyzacji.
Powiedzieliśmy już, że API daje możliwość wymiany danych w ramach aplikacji oraz pomiędzy aplikacjami. To prowadzi nas do zupełnie nowych możliwości. Okazuje się, że jesteśmy w stanie łączyć ze sobą różne usługi z których korzystamy i przesyłać pomiędzy nimi dane. W ten sposób nie jesteśmy już ograniczeni funkcjami dostępnymi w wybranych aplikacjach, lecz mamy do dyspozycji pełen wachlarz możliwości, które dają nam wszystkie wykorzystywane przez nas narzędzia!
Jak to możliwe? Otóż programiści udostępniają dostęp do swojego API nie tylko ich własnym aplikacjom (przykładowo aplikacja mobilna i przeglądarkowa Twojego banku), ale także... innym developerom, którzy mogą budować rozwiązania w oparciu o ich software.
Tymi innymi developerami będziemy my, używając narzędzi, które są wyspecjalizowane w konkretnym zadaniu - wysyłaniu maili (np. Mailchimp), SMSów (np. Twilio), wzbogacaniu danych klientów (np. Clearbit), notyfikowaniu działu sprzedaży (np. Slack) etc. i łącząc je ze sobą właśnie w ramach Automatyzacji. Dzięki takiemu podejściu, nie będziemy musieli nigdy logować się do graficznego interfejsu aplikacji, z których korzystamy, przykładowo do wysyłki maili marketingowych. Automatyzacja zrobi to za nas, "logując" się do API i wysyłając maile konkretnej treści, do oznaczonej grupy odbiorców. Można powiedzieć, że dzięki temu już nigdy my, ani nasi pracownicy nie będą musieli logować się (i zapominać haseł;) do internetowych usług, z których korzystamy, a które mają dobre, dostępne API.
Korzyści, które płyną z takiego podejścia to między innymi: