Spotkałem ostatnio ciekawy problem i się zacząłem zastanawiać....
Jeśli tworzysz aplikację i używasz 3rd party API to czy powinno się go używać bezpośrednio z tej aplikacji czy powinno się mieć swoją warstwę między apką a API?
I tak, zawsze trzeba mieć warstwę abstrakcji i pytaniem nie jest czy z kodu biznesowego wprost wołać to API, czy jednak mieć klienta, który woła API... bo powinno się mieć to drugie ;-) [w skrócie to ułatwi testy i w razie zmian w tym API nie trzeba będzie zmieniać za dużo kodu, a tylko "klienta"]
Ale czy jak to jest aplikacja na urządzeniu (telefon, tablet, komputer, zegarek, telewizor, samochód, łódź, statek kosmiczny czy kuchenka mikrofalowa ;-)) to czy powinno się wołać cudze API wprost z urządzenia czy wołać swoje API na swoim serwerze i dopiero stamtąd wołać to 3rd party API?
No i wyszło mi, że to jest funkcja tego jak często można zrobić update apki, jak krytyczne jest to API dla działania apki i tego jaka jest stabilność tego API (w sensie tak samego API, czyli czy często się zmienia i w sensie też stabilności czyli tego jak często pada ;-)).
No bo jeśli to jest apka na telefon (czyli miejsce gdzie updaty są praktycznie natychmiastowe (chociaż w Apple nie do końca ;-)), to jest dodatkowa niekrytyczna funkcjonalność apki i samo API jest stabilne (w obu znaczeniach) to można używać wprost.
Ale im gorzej z updatami, gdy użycie API jest coraz bardziej krytyczne, gdy stabilność nie jest najwyższa to wtedy jestem za stawianiem własnego kawałka kodu, który odwala kontakty z API.
Bo zawsze można nadrobić proces updatowania zmieniając tylko bebechy naszego serwisu nie ruszając apek, zawsze łatwiej przykryć tak zmiany w samym API i w razie przerw w działaniu używać cache'a (jeśli ma sens), do tego jeszcze nie trzeba czekać na to jak ktoś zaimplementuje funkcje (coś w stylu, jeśli każde urządzenie będzie musiało zrobić dzień w dzień 100 call'i tylko po to by sobie zebrać jakąś listę bo API nie ma tej listy to dostawca API będzie zły no i to potrwa, ale jak tą listę tworzymy w taki sposób "u siebie" w serwisie i w razie czego dajemy tą listę apce to nikt się nie będzie czepiał).
Czyli swoją warstwę trzeba mieć im bardziej będzie bolał jej brak ;-)
I co ciekawe jako ktoś kto dostarczał i dostarcza API często widziałem (i widzę ;-)), że "klienci" bardzo często chcą swoje apki doprowadzić do stanu, że to są tylko UI do cudzego API i nie widzą wad tego rozwiązania... do czasu gdy słyszą "nie" na feature request i wtedy jest panika, bo przecież im nie będzie działać.... i jeszcze bardzo często reagują zdziwieniem, a nawet oburzeniem, na propozycję "ej to zaimplementujcie sobie sami to, a jak my za 3 miesiące czy rok dodamy tą funkcjonalność to się na to przepniecie, albo będziecie nadal używać tego swojego kodu". Odpowiedzi są zwykle w stylu "ale to będziemy musieli skasować ten kod", albo "ale to nie pasuje do naszej architektury" i podobnymi, które zwykle sprowadzają się do tego, że zrobili błędne założenia i nie chcą się z nich wycofać.
Podobne postybeta
Branche i Scrum to taki security blanket dla programistów
Rant po toolach w stylu Mavane, Gradle, Bowera i całej tej hałastry
Integracja
Smutno mi się zrobiło...
Spadochronowy atak na Wawel - czyli wolne GWT
Brak komentarzy:
Prześlij komentarz