Family Finance Tracker – “Stos technologiczny” aplikacji

java programmer

 

W poprzednim wpisie opisywałem aplikację Family Finance Tracker pod względem funkcjonalnym. Zakres prac do pierwszej wersji, która zostanie upubliczniona, jest już zamknięty. Na chwilę obecną pracuję jedynie nad dopracowywaniem tych funkcjonalności. Myślę zatem, że nadeszła najwyższa pora, żeby podzielić się z Wami informacjami, w jaki sposób, od strony technicznej, aplikacja została zbudowana, i jak to się stało, że jeden programista w około 3 miesiące był w stanie zrobić działającą aplikację jednocześnie na Android’a, iOS, a także wersję działającą w przeglądarce WWW.

Wpis jest dość mocno techniczny, więc osoby nie związane z IT, mogą nie do końca być zainteresowane tą tematyką. Jeśli tak będzie, z góry przepraszam. Starałem się jednak dość prosto tłumaczyć zagadnienia, które poruszam, więc myślę, że te osoby mogą w tym wpisie również znaleźć coś ciekawego.

Moje doświadczenia

 

Abym w pełni mógł uzasadnić swoje decyzje techniczne, warto wspomnieć, czym zajmuję się zawodowo.

Od około 10 lat pracuję jako programista w jednej z firm ubezpieczeniowych. Tam, na co dzień zajmuję się systemem produktowym do ubezpieczeń na życie, mającym dość duży związek z rozliczeniami finansowymi, jak i z inwestycjami. Programuję w Javie, do przechowywania danych wykorzystujemy bazę SQL’ową, a do budowania interfejsu użytkownika niedawno zaczęliśmy wykorzystywać framework Angular 5. Dodatkowo, wykorzystujemy frameworki takie jak Spring i Hibernate.

Założenia

 

Kiedy przyszedł nam do głowy pomysł budowy swojej aplikacji do zarządzania budżetem domowym,  zaczęliśmy się zastanawiać jak duża będzie skala rozwiązania, które planujemy zrobić praktycznie wyłącznie własnymi siłami – przynajmniej początkowo. Doszliśmy do wniosku, że nie możemy pozwolić sobie na wykorzystanie zupełnie nieznanych mi technologii, ponieważ znacznie wydłużyłoby to przygotowanie tzw. MVP (Minimum Viable Product – czyli minimalnej wersji aplikacji, która spełnia podstawowe potrzeby Użytkowników, oraz jest bazą do dalszego rozwoju).

Chcieliśmy jak najszybciej przygotować narzędzie, z którego sami będziemy mogli korzystać, ponieważ tak jak pisaliśmy w pierwszym wpisie, korzystanie z Google Docs stało się dla nas dość uciążliwe. Chcieliśmy również, już na początkowym etapie dać znać osobom, które mogłyby być zainteresowane taką aplikacją, że nad nią pracujemy.

Głównym naszym założeniem jest, że aplikacja musi być wieloplatformowa. Musi działać w przeglądarce internetowej, ale również na urządzeniach mobilnych z systemami Android oraz iOS. Konieczna jest też pełna, natychmiastowa i wygodna synchronizacja danych nie tylko pomiędzy różnymi urządzeniami, ale również pomiędzy wieloma użytkownikami tak, aby z aplikacji jednocześnie korzystać mogli wszyscy członkowie rodziny.

Standardowo, aby przygotować rozwiązanie tego typu potrzebujemy:

  1.  “backendu”, czyli aplikacji działającej na zdalnym serwerze, przyjmującej żądania od wszystkich użytkowników, ze wszystkich platform (przeglądarka, urządzenia mobilne)
  2.  bazy danych
  3.  “frontendu”, czyli aplikacji działającej w przeglądarce internetowej
  4.  aplikacji mobilnej na Android’a
  5.  aplikacji mobilnej na iOS

Już na pierwszy rzut oka widać, że pracy sporo – cztery odrębne aplikacje i baza danych.

Backend

spring boot

Tak jak pisałem wcześniej, na co dzień programuję w Javie, pierwszym wyborem było zatem dla mnie wykorzystanie Spring Boot’a (https://spring.io/projects/spring-boot). To rozwiązanie na pewno znane jest wszystkim programistom Java’owym. Pozwala na korzystanie z wszystkich dobrodziejstw frameworku Spring, jednocześnie zapewniając szybką i wygodną konfigurację. To narzędzie bardzo często stosowane jest zarówno w małych aplikacjach, jak i tych klasy Enterprise. Jest bardzo dobrze przetestowane, stabilne, ma bardzo dużą społeczność, co zapewnia szybkie wsparcie w razie problemów. Nie ukrywam jednak, że jednym z ważniejszych kryteriów, które zadecydowało o jego wyborze, było to, że dość dobrze je znam, więc “próg wejścia” miałem bardzo niski – mogłem od razu skupić się na funkcjonalnościach aplikacji, a nie na “walce z technologią”.

Baza danych

postgresql

Przy wyborze bazy danych miałem spory dylemat. Standardowo korzystam z baz relacyjnych (SQL), jednak coraz większą popularnością cieszą się różnego rodzaju bazy obiektowe (noSQL), z którymi jednak praktycznie nie miałem styczności. Bardzo kuszące było, żeby niejako przy okazji tworzenia nowej aplikacji “pobawić się” trochę tego typu bazami. Po lekturze szeregu artykułów w Internecie, oraz przeanalizowaniu na forach wielu wojen pomiędzy zwolennikami jednego i drugiego podejścia, doszedłem do wniosku, że stawiam jednak na SQL. Rodzaj danych, które będą przechowywane w aplikacji Family Finance Tracker będzie mocno ustrukturyzowany. Bazy noSQL nadają się bardziej do aplikacji, w której schemat danych nie jest jasno zdefiniowany i sztywny. Zwyciężył zatem zdrowy rozsądek. Zdecydowałem się na bazę PostgreSQL, która jest jedną z najpopularniejszych baz SQL. Poza tym jest bardzo duży wybór hostingów i “chmur”, które oferują Postgres’a w swoich usługach.

Frontend, Android, iOS, PWA

ionic

Pierwszy plan zakładał, że na początku powstanie aplikacja przeglądarkowa przy wykorzystaniu frameworku Angular 6. Niejako równolegle chciałem pracować nad wersją na Androida, ponieważ tutaj miałem już jakieś doświadczenie. Stwierdziłem, że na sam koniec zostawię sobie wersję na iOS, szczególnie, że nawet nie miałem żadnego Mac’a, bez którego wersji na iOS nie da się wydać.

Niejako przypadkiem natrafiłem jednak na framework IONIC (https://ionicframework.com/), który rzekomo pozwala na napisanie jednej wersji aplikacji i uruchomienie jej w przeglądarce, ale również skompilowanie do natywnej aplikacji Android’a i iOS’a. Dodatkowo można przygotować tzw. aplikację PWA (Progressive Web App), którą można z poziomu przeglądarki dodać do ekranu głównego telefonu i będzie zachowywała się praktycznie tak samo, jak aplikacja natywna.

Z założenia dość sceptycznie podchodziłem dotychczas do tego typu rozwiązań, jednak wizja pisania tylko jednego kodu aplikacji na wszystkie urządzenia dość mocno do mnie przemawiała. Zrobiłem mały “research” w internecie. Okazało się, że framework jest dość popularny, było już sporo wdrożeń różnego rodzaju aplikacji, zakończonych sukcesem.

W momencie, gdy zaczynałem pracę, stabilną wersją był IONIC v3.  W tym samym czasie ukazała się jednak pierwsza wersja beta IONIC v4, która wprowadza bardzo wiele zmian, niekiedy łamiąc wsteczną kompatybilność z poprzednimi wersjami. Nie chciałem zatem już na początku prac mieć z tyłu głowy myśli, że gdy zdecyduję się na korzystanie z wersji stabilnej, za chwilę będę musiał migrować aplikację do wersji 4. Podjąłem zatem ryzyko i zacząłem pisać od razu w niezbyt jeszcze stabilnej wersji. Stwierdziłem, że zanim prace będą bardzo zaawansowane, framework się ustabilizuje. Dodatkowym argumentem było to, że IONIC v4 pozwala na pisanie w praktycznie czystym Angularze 6. Można korzystać z większości Angularowych pakietów i bibliotek.

Patrząc z punktu widzenia czasu, mogę stwierdzić, że była to bardzo dobra decyzja. Na początku miałem sporo problemów. Pojawiały się różnego rodzaju dziwne błędy. Spędziłem sporo czasu szukając ich w swoim kodzie, a kilkukrotnie okazywało się że były to błędy w samym IONIC’u. Na szczęście w większości przypadków wystarczyło zrobić aktualizację do kolejnej bety i błąd znikał.

Przekonałem się jednak, że podejście – jeden kod, wszystkie platformy, w tego typu aplikacjach naprawdę działa. Zaoszczędziło mi to mnóstwo pracy. Dzięki temu, dodając nową funkcję w aplikacji web’owej, jest ona od razu dostępna na wszystkich platformach. Idealne rozwiązanie… 🙂

Logowanie

firebase

W aplikacjach tego typu, kluczowe jest bezpieczeństwo danych Użytkowników. Stworzenie mechanizmu logowania użytkowników, który spełni wszystkie standardy bezpieczeństwa, nie tylko jest bardzo czasochłonne, ale również bardzo skomplikowane. Dlatego tutaj również zdecydowałem się na skorzystanie z gotowego rozwiązania dostarczanego przez Google – Firebase.

W jednym narzędziu otrzymujemy możliwości logowania przez większość mediów społecznościowych, jak również za pomocą adresu email. Firebase zapewnia dobre wsparcie zarówno dla Angulara (czyli również IONIC’a), jak również dla Javy i Springa. Dzięki temu stosunkowo szybko udało mi się przygotować odpowiednie zabezpieczenia.

Hosting

google cloud

Tutaj w grę wchodziły dwa rozwiązania. Swój dedykowany serwer, lub hosting “w chmurze”. Każde z tych podejść ma swoje plusy i minusy. Na chwilę obecną wygrała druga opcja. Zdecydowałem się na hosting w Google Cloud – zarówno bazy danych jak i samej aplikacji backendowej i przeglądarkowej.

Głównym czynnikiem było to, że w przyszłości, gdyby liczba użytkowników aplikacji wzrosła, w prosty sposób będę mógł skalować zarówno bazę danych, jak również samą aplikację. Muszę jednak stwierdzić, że nie jest to rozwiązanie tak proste jak jest reklamowane.

Zmigrowanie aplikacji z własnego serwera, na którym miałem wersję testową, do produkcyjnej chmury zajęło mi pięć wieczorów. Mimo, że wszelkie tutoriale oraz dokumentacja podawały rozwiązania, które powinny zadziałać “od ręki”, to moja aplikacja nie chciała się uruchomić. Pomogło dopiero przygotowanie dedykowanych, własnych skryptów instalacyjnych do Dockera. Docker jest to platforma kontenerów aplikacyjnych wykorzystywana przez Google Cloud.

Reasumując, obecnie hosting w Google Cloud działa już bardzo dobrze i stabilnie, jest jednak jeden problem – koszty :-). Nie jest to rozwiązanie tanie. Osobno płaci się za transfer, osobno za liczbę instancji bazy danych, osobno za liczbę instancji aplikacji, osobno za każdy wykorzystywany rdzeń procesora, osobno za Firebase’a do logowania, i tak dalej… Generalnie sposób naliczania opłat jest dość skomplikowany a i ceny do najniższych nie należą. Na początek otrzymuje się 300$ do wykorzystania, ale te pieniądze znikają niestety dość szybko, nawet przy znikomym obciążeniu serwerów 🙁

Podsumowanie

 

Przy tego typu projektach wybór technologii nigdy nie jest prosty. Za każdą przemawiają różne argumenty. Błędne decyzje będą ciążyły już do końca, ponieważ rzadko kiedy można sobie pozwolić na przepisanie aplikacji od początku. Zawsze potrzebne są pewne kompromisy, szczególnie jeśli do dyspozycji mamy ograniczone zasoby. Sądząc po tempie rozwoju aplikacji, które w mojej opinii jest całkiem niezłe, wybór był dobry. Zdecydowałem się na popularne i sprawdzone frameworki (nawet IONIC, w którym dużą część stanowi bardzo popularny Angular), więc w przyszłości może być stosunkowo łatwo znaleźć chętnych do pomocy. Jeśli macie jakieś dodatkowe uwagi lub przemyślenia, podzielcie się proszę nimi w komentarzach.

2 myśli na temat “Family Finance Tracker – “Stos technologiczny” aplikacji

Dodaj komentarz