Z pamiętnika SaaSa: Jak wybrać typ aplikacji tworząc aplikację SaaS?

Mając już pomysł na aplikację, należy zdecydować się jak ją zaimplementujemy. Czy ma to być aplikacja Desktop, a może od razu idziemy na smartfony? W tym artykule opiszę wady i zalety różnych typów aplikacji oraz pokażę jakie czynniki zadecydowały, że wybrałem taki, a nie inny rodzaj do swojej aplikacji SaaS easyRenti.

Typy aplikacji

Jedną z najważniejszych decyzji, którą trzeba podjąć gdy przystępujemy do pisania nowego programu jest typ aplikacji, który chcemy stworzyć. Od tej decyzji zależy bardzo wiele, gdyż wybierając jeden typ dostaniemy szereg możliwości, natomiast w innych aspektach będziemy mieli problem. Warto zatem poznać ogóle wady i zalety najbardziej popularnych typów aplikacji.

Aplikacja Desktop

Jest to jeden z najstarszych rodzajów aplikacji. Zwykle jest to program w postaci pliku wykonywalnego, który musimy najpierw zainstalować na naszym komputerze, zanim będziemy mogli z niego korzystać. Jeśli chodzi o aplikację SaaS to jest możliwe zaimplementowanie jej jako Desktop (patrz najnowsze wersje pakietu Adobe), jednak nie jest to najbardziej naturalny typ dla aplikacji subskrypcyjnych.

Zalety

• Integracja z systemem operacyjnym – w tego typu programie mamy dostęp zwykle do całego systemu operacyjnego, możemy wykorzystać większość specyficznych ficzerów dla danej platformy.
• Wydajność – aplikacja desktop zwykle daje nam największą wydajność i możliwości, stąd (przynajmniej do tej pory) takie aplikacje jak Adobe Photoshop, Adobe Premiere itp. to aplikacje typu Desktop
• Offline – zwykle tego typu aplikacja nie wymaga dostępu do Internetu, aby można było ją uruchomić.

Wady

• Deployment – użytkownik musi najpierw ściągnąć naszą aplikację, a potem ją zainstalować. Czasem nie może tego zrobić przez brak uprawnień Administratora systemu.
• Przywiązanie do konkretnej platformy – standardowo aplikacja Desktop pisana jest pod konkretny system operacyjny (aplikacje pisane w C++ lub C# i WPF). Aby mieć program na Windowsa i np. na MacOS trzeba włożyć sporo pracy. Oczywiście są różne frameworki, umożliwiające pisanie jednego kodu i budowanie go na wiele platform, ale zwykle te aplikacje mają mniejszą funkcjonalność, wydajność i gorszą integrację z systemem operacyjnym (czyli tracimy powyższe zalety)
• Utrudniona aktualizacja – za każdym razem, gdy wypuścisz nową wersję, musisz rozwiązać problem, jak tą aktualizację dostarczyć do obecnych użytkowników. Prawdopodobnie będzie trzeba stworzyć mechanizm aktualizacji. Co więcej nie wszyscy użytkownicy dokonają aktualizacji, więc w danym momencie będzie wiele różnych wersji Twojego programu. Taka sytuacja bardzo utrudni naprawianie błędów zgłoszonych przez użytkowników.
• Nie do końca pasuje do modelu SaaS

Aplikacja Internetowa

Aplikacja internetowa jest to po prostu strona WWW, która jednocześnie posiada logikę biznesową naszego programu. Użytkownik korzysta z niej za pośrednictwem przeglądarki internetowej. Jej dużym plusem jest to że mamy kontrolę nad całą aplikacją – wszyscy użytkownicy zawsze korzystają dokładnie z tej samej wersji, co znacznie upraszcza utrzymywanie kodu. Dodatkowo jest to najbardziej przenośny typ aplikacji – dobrze zaprojektowana aplikacja web powinna działać na większości dostępnych urządzeń, niezależnie od systemu operacyjnego.

Zalety

• Multiplatformowość – aplikację internetową uruchomimy na dowolnym systemie operacyjnym, a także na większości urządzeń. Nie musimy pisać odzielnej wersji na Androida i iPhona.
• Aktualizacje – wypuszczenie nowej wersji programu jest banalnie proste. Wrzucamy nową wersję na serwer i wszyscy użytkownicy od razu mają do niej dostęp. W każdej chwili istnieje tylko jedna (aktualna) wersja programu, co ułatwia naprawianie błędów, bo nie musimy ich naprawiać w starszych wersjach – wystarczy w najnowszej.
• Deployment – użytkownik, aby skorzystać z naszego programu, po prostu wchodzi na stronę i od razu ma dostęp. Nie musi nic instalować (pomijam aplikacje PWA).
• Popularny stack technologiczny – aplikacja webowa składa się z części serwerowej (u nas to ASP.NET Core) oraz frontendu pisanego zwykle w HTML oraz jscript. Nawet jeśli ASP.NET jest już specyficzną technologią to HTML i jscript są bardzo popularne, więc w miarę łatwo znaleźć programistę, który będzie w stanie pracować z naszym kodem.
• Duża ilość dostępnych bibliotek – dzięki temu, że aplikacje internetowe są bardzo popularne, istnieje bardzo wiele darmowych bibliotek, które możemy użyć, np. do rysowania wykresów, różnego rodzaju Gridy, itp
• Idealne dla modelu SaaS oraz SoloProgramisty
• Koszta – piszemy jedną aplikację, która będzie uruchamiana na wszystkich urządzeniach.

Wady

• Ograniczone możliwości – mimo, iż w obecnych czasach aplikacje internetowe mają coraz więcej możliwość (np. coraz większą integrację z systemem operacyjnym) to nadal ich możliwości są mocno ograniczone. W porównaniu z pozostałymi rodzajami aplikacji, aplikacje webowe mają mocno ograniczony dostęp do dysku twardego użytkownika, wysyłania powiadomień, zaawansowanych operacji graficznych itp. Mówiąc krótko, nie wszystkie pomysły na program, da się za ich pomocą zaimplementować lub implementacja będzie bardzo okrojona w możliwości.
• Brak trybu offline – standardowo tego typu aplikacje wymagają stałego dostępu do internetu. Częściowo rozwiązaniem jest aplikacja PWA, która wspiera tryb offline, jednak jego zaimplementowanie i tak byłoby czasochłonne.

Aplikacja PWA (Progressive Web App)

Jest to tak naprawdę aplikacja internetowa z dodatkowymi ficzerami, które sprawiają, że nasza strona bardziej przypomina „prawdziwą” aplikację mobilną. Ten typ aplikacji ma wszystkie zalety aplikacji internetowej, ale mniej wad.

Zalety

• Możliwy tryb offline – jest możliwe napisanie naszej aplikacji internetowej (PWA) w taki sposób, aby użytkownik mógł z niej korzystać bez dostępu do Internetu.
• Działa jak aplikacja mobilna – dla końcowego użytkownika nasz program wygląda i działa jak natywna aplikacja mobilna. Możemy dodać ją do sklepu Play lub AppStore, użytkownik może zainstalować skrót do programu na pulpicie, może dostawać powiadomienia, mamy dostęp do geolokalizacji oraz kamery itp.

A czy aplikacja PWA ma jakieś wady w porównianiu z aplikacją internetową? Moim zdaniem nie. Samo dodanie podstawowych ficzerów PWA do naszej strony jest banalnie proste i poświęcisz na to parę godzin. Jedynie implementacja trybu offline jest o wiele bardziej skomplikowana. Jednak nie masz obowiązku go dodawać.

Aplikacja mobilna (natywna)

W obecnych czasach większość użytkowników Internetu korzysta ze smartfona lub tabletu. Komputery PC lub laptopy coraz częściej są używane tylko w biznesie lub przez profesjonalistów do pracy (pomijam graczy w naszych rozważaniach). W związku z tym stworzenie aplikacji na telefon ma jak najbardziej sens. Dobrze zaprojektowana aplikacja mobilna jest prostsza w użyciu na małym ekranie niż nawet dobrze zaprojektowana aplikacja webowa.

Zalety

• Przyjazna dla użytkownika – dobrze zaprojektowana aplikacja mobilna zapewnia najlepsze doświadczenia dla użytkowników. A skoro większość i tak korzysta z Twojej aplikacji na telefonie, to stworzenie dedykowanej wersji programu na tego typu urządzenia ma sens.
• Integracja z systemem – aplikacja mobila potrafi w pełni zintegrować się z docelowym urządzeniem i wykorzystać wszystkie dostępne ficzery danej platformy
• Tryb offline – w miarę łatwo przystosować program do działania bez dostępu do Internetu
• Deployment – aplikacje mobilne są dostępne za pośrednictwem sklepów z aplikacjami (Google Play, AppStore), więc użytkownik, który chce skorzystać z Twojego programu, raczej nie ma problemu, aby go znaleźć i zainstalować.
• Aktualizacje – dzięki temu, że aplikacje są instalowane za pośrednictwem sklepu z aplikacjami, dostęp do nowych wersji dla użytkowników jest bardzo łatwy. Sam mechanizm updatów dostajemy praktycznie za darmo. Jednak, w odróżnieniu od aktualizacji aplikacji internetowej, tutaj nie jest tak różowo (o tym w wadach).
• Natywny wygląd – aplikacja korzysta z natywnych kontrolek danej platformy, więc bardzo dobrze pasuje wyglądowo do pozostałych programów, z których użytkownik korzysta.

Wady

• Multiplatformowość – na rynku są przynajmniej 2 dominujące platformy: Android i iOS. Więc teoretycznie trzeba napisać dwie niezależne aplikacje.
• Aktualizacje – w przypadku aplikacji mobilnych, aktualizacje mogą być problematyczne. Oczywiście sam mechanizm aktualizacji dostajemy za darmo (telefon automatycznie może zainstalować nowszą wersję programu), jednak nadal jest problem, z tym, że w danym momencie może istnieć wiele wersji Twojego programu (nie wszyscy użytkownicy instalują regularnie aktualizacje). Co gorsza, mogą być przypadki, że użytkownik przez rok nie aktualizował aplikacji i ma bardzo starą wersję. W momencie gdy ściąga update, musisz poradzić sobie z migracją danych (lokalnych) do nowego formatu. A co jeśli Twoja aplikacja korzysta z WebAPI, które cały czas rozwijasz? W takim układzie musisz wersjonować API i w każdej chwili utrzymywać wiele wersji.
• Koszty – prócz oczywiście kosztów związanych z pisaniem dwóch aplikacji (na Androida i iOS), to dochodzą jeszcze opłaty za umieszczenie aplikacji w sklepie Googla/Apple.

Aplikacja mobilna (multiplatformowa)

Obecnie na rynku jest coraz więcej technologi umożliwiających tworzenie jednej aplikacji, a następnie dystrybuowanie jej na różne platformy. W tym przypadku idziemy na kompromis zalet i wad aplikacji natywnych. Tutaj wszystko zależy od konkretnego narzędzia, które użyjemy. Różnice między nimi mogą być znaczące, więc decydując się na tego typu rozwiązanie, zalecam spory research. Źle dobrany framework, może być katastrofą dla całego projektu!

Zalety

• Multiplatformowość – piszemy jeden kod, który może być uruchamiany na różnych platformach (czasem nie tylko mobilnych). Niektóre tego typu narzędzia umożliwiają dodawanie kodu specyficznego dla konkretnej platformy, jednak większość kodu aplikacji jest wspólna.
• Mniejsze koszty – związane z powyższym punktem. Piszemy jedną, a nie kilka oddzielnych aplikacji. Zatrudniamy jeden zespół programistów itp
• Dobre dla soloprogramisty – soloprogramista zawsze szuka optymalizacji, a tego typu narzędzia mocno przyśpieszają pracę.

Wady

• Mniejsze możliwości – zależnie od wybranego frameworka. Jednak nie ma co się oszukiwać – na pewno nie dostaniemy pełnych możliwości natywnej aplikacji mobilnej. Dlatego koniecznie zapoznaj się z tym, co wybrane narzędzie oferuje, zanim zaczniesz projekt.
• Ryzyko – w przypadku źle dobranego narzędzia istnieje ryzyko, że albo projekt się nie uda, albo nasi programiści będą próbowali jakoś załatać braki danej technologii lub ostatecznie zaczną pisać od nowa aplikację natywnie. Widziałem takie sytuacje na własne oczy!

W tym przypadku, wady i zalety aplikacji natywnych także nadal obowiązują.

Rozszerzenie zewnętrznej aplikacji (plugin)

Sposobów, w jaki możesz zaimplementować swój program jest więcej. Jednym z oryginalniejszych jest stworzenie pluginu, który będzie rozszerzał możliwości zewnętrznej aplikacji o Twoją funkcjonalność. Oczywiście tego typu rozwiązanie ma sens w konkretnych sytuacjach, jednak w przypadku, gdy Twój pomysł na program pasuje do tego modelu, to na pewno warto wziąć go pod rozwagę.

Zalety

• Przyjazna dla użytkownika – często stworzenie pluginu daje użytkownikom najlepsze doświadczenia, gdyż Twój program jest bardzo dobrze zintegrowany z innym narzędziem, którego oni używają.
• Tryb offline – w przypadku oczywiście rozszerzenia do aplikacji, która nie wymaga dostępu do Internetu. W przypadku, gdy Twój plugin jest tylko klientem i łączy się z Web Serwisem, to oczywiście tryb offline może być problemem.

Wady

• Multiplatformowość – w przypadku pluginu, zwykle nie mówimy o różnych systemach operacyjnych, a raczej rożnych zewnętrznych programach, z którymi warto byłoby się zintegrować. Wyobraź sobie, że chciałbyś stworzyć plugin, dla grafików. W tym przypadku dobrze było by się zintegrować z Adobe Photoshop. A co z Corel Draw, Gimp i innymi narzędziami – będziesz tworzyć plugin dla każdego z nich? A co z różnymi wersjami aplikacji, z którą się integrujesz? W przypadku rozszerzenia do Adobe Photoshop, z jak starą wersją chcesz się zintegrować? W zależności od decyzji, albo odcinasz pewną część użytkowników, którzy korzystają ze starszej wersji, albo będziesz miał więcej pracy związanej z tworzeniem i utrzymaniem swojego pluginu.
• Rozpoznawalność – dla niektórych użytkowników, Twój plugin będzie postrzegany jako część zewnętrznej aplikacji, a nie jako oddzielny produkt
• Aktualizacje – podobnie jak w przypadku aplikacji Desktop lub mobilnych. W danej chwili może być używanych wiele wersji Twojego rozszerzenia. Użytkownicy mogą aktualizować bardzo stare wersje, dlatego musisz obsłużyć migrację danych z dowolnej starej wersji pluginu do najnowszej.
• Ograniczony wybór technologii – zwykle pluginy pisze się w konkretnym jezyku programowania, co sprawia, że nie mamy tutaj dużych możliwości wyboru. Jest spore ryzyko, że będziemy musieli się najpierw nauczyć danego języka programowania.

Stworzenie pluginu jest ciekawą opcją, jednak nawet w przypadku, gdy ma ona sens, to nie zawsze bym ją rekomendował na początek. W przypadku mojej aplikacji easyWSDL, wybrałem podejście inne. Sama aplikacja jest generatorem klas, które umożliwiają programistom komunikację z web serwisami SOAP na platformie Android, iOS (Objective-C i Swift) oraz Java.

Teoretycznie mógłbym stworzyć mój generator tylko jako plugin, ale wtedy musiałbym stworzyć wersje dla Android Studio, InteliJ, XCode i może jeszcze innych IDE. Ja wybrałem podejście inne. Stworzyłem aplikację webową, dzięki czemu każdy programista, niezależnie z jakiego IDE korzysta, może użyć mojego generatora. Nie jest to tak naturalne jak korzystanie z pluginu, ale przynajmniej działa dla wszystkich. Dopiero po 2 latach działania aplikacji webowej, stworzyłem plugin dla Android Studio i InteliJ, co na pewno ułatwiło programistom korzystanie z mojego rozwiązania, jednak nie było tak naprawdę niezbędne.

Który typ wybrać?

Nie będę oryginalny mówiąc, że to zależy 🙂 Warto dobrze zastanowić się nad tym wyborem, gdyż będzie miał on konsekwencje przez cały czas trwania projektu (i działania aplikacji). Najważniejszym czynnikiem, który wpływa na wybór jest to, co Twoja aplikacja ma robić. Bardziej specjalistyczne lub wymagające aplikacje trzeba zaimplementować jako Desktop. Wyobraź sobie, że chcesz stworzyć program antywirusowy. Nie zaimplementujesz go jako aplikacji internetowej. Twoim jedynym wyborem jest desktop, gdyż tylko ten typ aplikacji pozwala na doskonałą intergrację z systemem operacyjnym.

Z drugiej strony, wiele programów nie integruje się z systemem operacyjnym. W przypadku aplikacji do notatek nie ma takiego problemu. Aplikacja jest typowym CRUDem, czyli korzysta z bazy danych do przechowywania danych użytkownika i wyświetla interface, który umożliwia przeglądanie danych. W takiej sytuacji każdy powyższy typ się nadaje. Co więcej, wiele większych firm tworzy oddzielne aplikacje na każdą platformę: dedykowane aplikacje typu Desktop na Windows i MacOS, natywne aplikacje na Androida i iOS, a także aplikację webową.W sytuacji, gdzie koszty nie grają roli i najważniejsze są doświadczenia użytkowników, to takie podejście jest właściwe.

W przypadku soloprogramisty lub mniejszych firm IT, jest to na szczęście niepotrzebne. Lepiej wybrać jeden typ aplikacji i na nim się skupić. W easyRenti zdecydowałem się na aplikację PWA, gdyż jako aplikacja do zarządzania najmem mieszkań, jest typowym CRUDem. Nie wykorzystuję specjalnie możliwości różnych platform. Pewnie mógłbym wykorzystać jakiś ciekawy ficzer z Windowsa lub MacOS, jednak dla mnie ważniejsze jest to, żeby jak najmniejszym kosztem zrobić aplikację, która zaspokoi potrzeby 99% użytkowników. I aplikacja PWA daje taką możliwość. Każdy użytkownik, na dowolnym urządzeniu (laptopie, tablecie czy smartfonie) będzie w stanie korzystać z mojego programu. Oczywiście strona jest napisana responsywnie, ale w przypadku wykorzystania frameworków w stylu Bootstrap, nie jest to duży problem.

Dlaczego połączenie związek SoloProgramisty z PWA się opłaca?

Dzięki temu, że piszę tylko jedną aplikację, oszczędzam mnóstwo czasu. Dodanie nowego ficzera jest relatywnie proste. Wyobraź sobie, że napisałeś oddzielną aplikację na iOS, Android oraz Desktop i dodajesz nową funkcjonalność. Nie dość, że musisz ją zaimplementować w 3 programach, to jeszcze musisz je wszystkie przetestować, a potem każdy błąd naprawiać w 3 miejscach. Jak piszesz dokumentację, to robisz to x3, itp. Zaczynając projekt zadaj sobie pytanie, czy jest sens wchodzenia w kilka aplikacji od razu. Jeśli nie masz kilku programistów i konkretnych powodów, to uważam, że nie. Zwłaszcza jak nie wiesz, czy Twój program w ogóle się spodoba. Co jeśli nikt nie będzie go używać? Lepiej „zmarnować” czas na 1 aplikację, niż na 3.

A co w sytuacji, w której mógłbyś zaimplementować swój program jako aplikację internetową jednak wiesz, że gdybyś zrobił ją jako desktop czy natywną aplikację mobilną, to mógłbyś zaoferować użytkownikom więcej ficzerów lub lepsze doświadczenie? Jako soloprogramista musisz iść na kompromis i dokonać suchej analizy zysków i strat. Odpowiedz sobie na pytania:

• Co takiego będziesz mógł zaoferować użytkownikom, gdy wybierzesz aplikację natywną?
• Na ile Twoja aplikacja straci, gdy zrobisz ją jako aplikację webową?
• Ile więcej czasu zajmie stworzenie 3 aplikacji natywnych (Windows+Android+iOS) zamiast jednej aplikacji PWA?
• Czy, zamiast poświęcić tą dodatkową ilość czasu na aplikacje natywne, nie lepiej jest po prostu dodać nowe funkcjonalności do Twojego programu?

Przykład:

Jak wspomniałem, easyRenti jest aplikacją do zarządzania najmem mieszkań. Stworzyłem ją jako aplikację PWA. Dzięki temu mam pokrycie wszystkich platform:

• Komputery (Windows, MacOS, Linux)
• Smarftony i tablety (Android, iOS)
• Web
• i wiele innych mniej popularnych platform, o których nawet nie wiem, że istnieją.

Czy zyskałbym coś gdybym zaimplementował easyRenti jako aplikacje natywne na każdej z tych platform? Pewnie tak, jakaś integracja w stylu: jak w Windows klikniesz prawym myszy na pliku pdf to pojawiłaby się opcja w menu Wyślij do easyRenti lub możliwość integracji z pakietem MS Office. Jednak w mojej ocenie nie są to ficzery, bez których aplikacja nie ma sensu. Są to fajne dodatki, ale tylko dodatki. Nie widzę potrzeby poświęcać teraz 3 razy więcej czasu na pisanie (i utrzymywanie) aplikacji natywnych dla tak małych usprawnień.

Zagrożenia

Wybierając konkretny typ aplikacji decydujemy się na pewien kompromis. Nie ma jednego, idealnego rodzaju programu. Osobiście głównie kieruję się łatwością stworzenia i utrzymywania. Z tego punktu widzenia aplikacja PWA jest najlepsza. Zaraz po niej są mobilne aplikacje multiplatformowe. Jednak w ich przypadku chciałbym Cię przestrzec, bo właśnie w nich widzę największe zagrożenie dla powodzenia projektu.

Problem z tymi programami jest taki, że twórcy narzędzi do ich tworzenia (Xamarin, Cordova itp) obiecują często więcej niż potrafią zaoferować. Narzędzia te są reklamowane w taki sposób, iż pisząc jeden kod, dostajemy aplikacje mobilne na wszystkie platformy z prawie takimi możliwościami co aplikacje natywne. Nie znam wszystkich multiplatformowych frameworków, jednak z moich doświadczeń wynika, iż nie jest to prawda. Programy, które za ich pomocą możemy stworzyć, mają różne ograniczenia. Jedne frameworki mają tych ograniczeń więcej, a inne mniej. Jednak wszystkie jakieś mają. I nie byłoby z tym żadnego problemu, gdyby programiści zdawali sobie z nich sprawę.

Pisząc aplikację internetową (lub nawet PWA) od razu spodziewamy się szeregu ograniczeń – w końcu strony internetowe mają bardzo ograniczone możliwości. Często możemy się mile zdziwić, bo zakładaliśmy, że nasza aplikacja webowa nie będzie mogła korzystać z dobrodziejstw systemu (np z mikrofonu, kamery lub lokalizacji), a tutaj niespodzianka – przeglądarka internetowa udostępnia pewne usługi stronom internetowym.

W przypadku multiplatformowych aplikacji mobilnych wielu programistów już nie zakłada istnienia dużej ilości ograniczeń. I w takiej sytuacji, po paru miesiącach rozwijania projektu, może się okazać, że dotychczasowa praca idzie do kosza i zaczynasz od nowa.

Podsumowanie

Wybór typu aplikacji jest jedną z najważniejszych decyzji w całym projekcie. Warto jest patrzeć na nią przez pryzmat zysków i strat (czysto ekonomicznie). Bardzo łatwo na początku wpakować się w coś co okaże się, że nas przerasta. W przypadku soloprogramisty szukałbym możliwości stworzenia jednej aplikacji, która będzie dla wszystkich użytkowników. Nawet kosztem pewnym kompromisów jeśli chodzi o funkcjonalność, czy wygląd programu. Jednak pamietaj, żebyś był świadom tych kompromisów. Bo, jeśli się dowiesz w połowie projektu, że najważniejszej funkcjonalności Twojego programu nie da się zaimplementować w wybranej przez Ciebie technologii, to masz problem.

Tags: ArchitekturaeasyRentieasyWSDLProgramowaniePWASaaSSoloProgrammingTypy aplikacjiZ pamiętnika SaaSa