Szybka akcja #1 – Play Framework

Jesteśmy obecnie w trakcie okresu w roku, w którym poziom naszej motywacji sięga najwyższych wartości. Jednym z moich postanowień na rok 2017 jest zaoszczędzenie pewnej sumy pieniędzy. W związku z tym stwierdziłem, że potrzebuję w jakiś sensowny sposób mieć wgląd w swoje wydatki, aby móc je stale kontrolować, analizować i na bieżąco korygować. W ten sposób powstał pomysł na napisanie aplikacji, która będzie zaspokajała podstawowe potrzeby w tym temacie.

Chwilę zastanawiałem się nad wyborem stosu technologicznego. Pierwszą myślą był Spring + „coś do frontu”, ale po jakimś czasie stwierdziłem „ileż można, trzeba czegoś nowego żeby się nie zanudzić”. Jako, że wcześniej miałem już chwilową styczność z Play Framework (kurs na Udemy) to stwierdziłem, że ten projekt będzie wspaniałą okazją do zgłębienia wiedzy na jego temat. Dalsze rozmyślania nad nauką nowego narzędzia doprowadziły mnie do pomysłu na sposób w jaki ten projekt będzie realizowanyy. Kluczowym stwierdzeniem w tym temacie było „szybkie weekendowe akcje, w trakcie których rozpoznaję daną technologię”.

Tak powstał pomysł na serię wpisów „Szybka akcja”. Będę w niej opisywał moje odczucia na temat narzędzi, które będę rozpoznawał na potrzeby małych projektów. Na pierwszy ogień idzie Play Framework.

Hobusu

HOme-BUdget-SUpervisor to prosta aplikacja, w której użytkownik będzie miał możliwość zapisywania swoich przychodów oraz wydatków. Aplikacja będzie udostępniała prosty interfejs, dzięki któremu możliwa będzie analiza funduszy. Prezentacja danych w przejrzysty i prosty sposób pozwoli na szybkie wyciąganie wniosków, które pozwolą optymalizować proces oszczędzania. Kod aplikacji Hobusu jest dostępny w serwisie Github.

Play Framework

Pierwszą styczność z narzędziem Play Framework miałem podczas realizacji kursu w serwisie Udemy, w którym autor przeprowadzał uczestnika lekcji przez kolejne etapy tworzenia prostej aplikacji.

Podczas realizacji pierwszego etapu aplikacji Hobusu urzekły mnie w nim głównie dwie rzeczy. Są to szybkość developmentu oraz ilość kodu niezbędnego do działania danej funkcjonalności.

Szybkość developmentu

Play Framework został wyposażony w serwer, który może zostać uruchomiony w trybie deweloperskim. Tryb ten dostarcza rozszerzenie w postaci kompilacji oraz restartu aplikacji w trakcie odebrania nowego żądania do serwera. Dzięki niemu proces wprowadzania zmian w kodzie jest bardzo prosty – dopisujemy kod, zapisujemy plik, wysyłamy żądanie i widzimy zmiany. Wyeliminowany jest tutaj krok polegający na ręcznej kompilacji oraz ponownym uruchomieniu aplikacji. W przypadku małej aplikacji jaką jest Hobusu serwer szybko reagował na zmiany i natychmiastowo dostarczał edytowaną wersję aplikacji. Jestem ciekaw jak sprawdzi się to w przyszłości, gdy aplikacja nieco urośnie.

Prawdopodobnie konsola SBT dostarcza dużo więcej funkcjonalności, o których nie mam jeszcze pojęcia, ale w przyszłości prawdopodobnie je wykorzystam. Więcej informacji można odnaleźć w oficjalnej dokumentacji.

Mniej kodu i zmieszania

Rozwijając projekty w Spring Framework byłem przyzwyczajony do dużej ilości kodu, który się powtarzał oraz do dużej ilości adnotacji, które zapewniały podstawową konfigurację. W Play zastosowano  nieco inne podejście do tych problemów. Żeby nie być gołosłownym poniżej przedstawię kilka przykładów.

Pierwszym z nich jest sposób rejestracji kontrolerów. Spring dostarcza adnotacje @(Rest)Controller, do której musimy jeszcze używać @RequestMapping, aby zmapować adres z akcją. W Play Framework problem ten został rozwiązany za pomocą pliku routes oraz klasy play.mvc.Controller. Składnia pliku routes  jest banalna:

Mam wrażenie, że dzięki takiemu rozwiązaniu klasa kontrolera jest bardziej czytelna.

Kolejną oszczędnością jest sposób zwracania danych przez akcje.

vs.

Nieco mniej kodu, a funkcjonalność pozostała ta sama.

Play Framework dostarcza/wykorzystuje narzędzie EBean ORM z klasą com.avaje.ebean.Model, dzięki której tworzenie kolejnych encji jest bardzo proste i nieco szybsze niż tworzenie warstwy repository i wstrzykiwania jej implementacji do modelu. Przy okazji wspominania o modelach warto zwrócić uwagę na odmienną konwencję tworzenia klas encyjnych. Zamiast tworzyć pola jako prywatne i generować do nich getery i setery to tworzymy pola publiczne. Na chwilę obecną nie jestem w stanie ocenić, które podejście jest dla mnie wygodniejsze – czas pokaże.

Dokumentacja

Napotkane dotychczas problemy zostały w 95% rozwiązane przy pomocy oficjalnej dokumentacji Play Framework. Jest ona bardzo czytelna i dostarcza wyczerpujących wyjaśnień na temat danego zagadnienia. Dostarczane przykłady pomagają podczas implementacji problematycznych rozwiązań.

Podsumowanie

Play Framework to narzędzie, któremu na pewno warto się przyjrzeć i poświęcić nieco czasu. Odczucia, które opisałem w tym poście wynikają z 3-dniowej przygody rozwijania podstawowej wersji API aplikacji Hobusu. Prawdopodobnie z upływem czasu wszystko zostanie zweryfikowane. Możliwe, że gdy aplikacja nieco urośnie, wymienione zalety Play Framework staną się jego wadami.

Kod aplikacji dostępny jest pod adresem mateuszbrycki/hobusu.

Przydatne linki

  1. Oficjalna dokumentacja Play Framework – https://www.playframework.com/documentation
  2. EBean ORM – http://ebean-orm.github.io/

You may also like

Comments