Budowanie architektury Twojego MVP

Przez ostatnie kilka miesięcy nie miałem czasu na publikowanie żadnych treści związanych z web aplikacjami. Większość czasu spędzałem nad nowym produktem! Projekt, który na celu ma zniwelowanie tworzenia CV na świecie. A jest nim teamrock.pro, czyli narzędzie wspomagające rekrutacje, skierowane dla działów HR, managerów IT, czy też ludzi na stanowisku CTO. O samym narzędziu nie będę się rozpisywał, bo nie o tym jest ten artykuł, natomiast chciałbym przedstawić Wam technologie jakie wybrałem do stworzenia tego projektu.

Laravel - Jeżeli poruszacie się w świecie PHP do wyboru macie dwa główne frameworki Symfony i oczywiście Laravel. Osobiście uważam, że jeżeli macie enterprise’owy projekt, o którym wiecie, że będzie on musiał być wspierany przez lata, to wybrałbym Symfony. Natomiast dla projektów typu MVP, gdzie nie ma jeszcze ustalonego na sztywno zakresu aplikacji, gdzie wszelkie funkcjonalności są “płynne” Laravel jest idealnym wyborem. Jest to framework typu RAD (Rapid Application Development), czyli taki który daje nam out of box uproszczoną/defaultową konfiguracje. Sam Fabien wspomina, że przeoczył tą okazję w porównaniu do LV, dlatego też powstał Symfony Flex.

Mongodb - Głównie wybrałem tą bazę ponieważ przez ostatnie kilka lat miałem z nią bliską styczność, lecz nie stoi na przeszkodzie, aby korzystać z mysql/postgreSQL. Lecz jako, że mongo jest bazą nie relacyjną, daje nam to możliwość tworzenia elastycznej struktury danych, co może być przydatne podczas tworzenia MVP i częstych zmian w produkcie. Równie przydatny może okazać się indeks pozwalający na kasowanie danych po upływie X czasu, który został zaimplementowany w mongo. Natomiast nie szalałbym tu z niszowymi bazami takimi jak GraphQL, CouchDB, RIAK KV, RethinkDB, i wiele, wiele innych. Tego typu bazy rozwiązują konkretne problemy, które nie zawsze muszą wystąpić w Twoim produkcie, dlatego warto się dwa razy zastanowić za nim ich użyjesz.

Vue.js - W swojej karierze programisty przeszedłem od czystego Javascriptu, po przez bibliotekę Jquery, następnie backbone.js, aż do Vue.js i na przełomie tych wszystkich lat widzę postępującą ewolucję w świecie JS. Muszę przyznać, że 5, czy 7 lat temu tylko mogłem pomarzyć o tego typu frameworku. Obecny teamrock.pro nie jest pierwszą wersją naszego narzędzia, wcześniej oparłem front o system templatek Blade dostępny out of box w Laravelu oraz domieszałem trochę Jquery dla dynamicznych elementów. Lecz przy 200 linijkach w Jquery kod staje się nieczytelny i ciężki do refactoringu, natomiast z vue.js nie ma czego się obawiać. Nawet osoba bez większego doświadczenia z javascriptem jest w stanie 2 tygodniw pojąć i napisać front pod webaplikacje. Po prostu dla powstającego produktu nie widzę prostszej drogi, nawet w porównaniu z angularem.

Vuetify.js - W jednym z swoich filmików wspominałem o dwóch bibliotekach Vuetify oraz Vuematerial, które są odzwierciedleniem Bootstrap w świecie vue.js. Tak jak przypuszczałem Vuetify się rozwinął i nie ma obecnie lepszej biblioteki tego typu. W poprzednim teamrocku najwięcej czasu schodziło na dopasowywanie elementów we frontencie. Zawsze ktoś z mojego teamu chciał, albo niestandardowy element w produkcie, albo żeby ten element był idealnie dopasowany pod każdym względem, nie mówiąc już o różnych rozdzielczościach. Spełnienie tego wszystkiego wymagało poświęcenia masakrycznie dużej ilości czasu, a jako, że produkt jest tworzony po godzinach, nie należało to do najprzyjemniejszych rzeczy. Dlatego też kiedy dowiedziałem się o vuetify wiedziałem, że jest to idealne rozwiązanie.

Na szczęście przyszedł czas, kiedy zespół chciał funkcjonalności, dostępnej out of box w bibliotece, dzięki czemu udało mi się ich przekonać abyśmy uprościli produkt i użyli tejże biblioteki w całym produkcie. Oczywiście na początku spowolniło to pracę, ale teraz zmiany są o wiele szybsze i przyjemniejsze. Jedyny minus jaki widzę, to częste update’y, w samej bibliotece, które nie zachowują kompatybilności wstecznej. Lecz powinno się to zmienić od wersji 1.0, która to niebawem nadejdzie.

Mailgun - Jak to w produkcie bywa potrzebujemy od czasu do czasu wysyłać maile naszym klientom. Już w poprzedniej mojej pracy poznałem wyśmienitego providera mailingowego Mailgun. Dzięki niemu nie musimy kłopotać się z instalacją Postfix’a, czy innego serwera mailowego oraz co ważniejsze nie musimy się przejmować, o to czy nasze wiadomości wpadną do spamu po przez nieprawidłową konfiguracje serwera. Mailgun pozwala na wysłanie 10 000 wiadomości za free, a wysyłka kolejnych wiadomości wcale nie jest droga. Tutaj także z pomocą przychodzi Laravel ponieważ konfiguracja Mailguna z LV to dosłownie kilka minut roboty.

Sentry.io - Po kilku tygodniach developmentu w przysłowiowej piwnicy przychodzi czas, aby nasze “dziecko” ujrzało światło dzienne. Tylko co zrobić z tymi wszystkimi błędami, które na pewno popełniliśmy podczas procesu tworzenia softu. Sprawdzanie co jakich czas logów z PHP na serwerze nie jest zbyt przyjazne. Natomiast odwzorowanie ścieżki błędu po stronie frontu, lub o zgrozo namówienie użytkownika do tego graniczy z cudem. Dlatego powstało narzędzie typu Sentry.io, które to wszystko robi za nas. Jeżeli pojawi się jakikolwiek błąd od strony backendu dostaniemy notyfikacje na maila, dzięki czemu od razu możemy reagować na wszelkie problemy. Natomiast od strony frontu jest jeszcze lepiej, bo będziemy mieli wszelkie potrzebne informacje, takie jak: z jakiej przeglądarki korzystał użytkownik, jakiej rozdzielczości używał, czy też ścieżkę jaką przeszedł w DOM’ie do czasu otrzymanie błędu javascript. A to wszystko za pomocą kilku linijek konfiguracji w vue.js, czystym javascripcie, czy też innym frontendowym frameworku. Parę minut i jesteśmy gotowi do działania.

Datadog - Kolejną rzeczą, o której warto pamiętać są logi samego serwera. Tutaj także przychodzi nam z pomocą zewnętrzna usługa. Tak jak poprzednio parę minut i mamy skonfigurowane przepiękne i użyteczne statystyki oraz alerty gdyby nasz serwer zbyt mocno się “spocił” w natłoku użytkowników. Do tego jeżeli postanowiliście użyć dockera macie możliwość podpięcia wszelakich statystyk związanych z kontenerami dockerowymi. To wszystko w cenie 0$ w podstawowym pakiecie, który to pod MVP w zupełności wystarczy.

Drone.io - Pewnie nie wiele osób o tym narzędziu słyszało, ale jest to prosty CI, który wykorzystujemy w naszym produkcie. Instalacja i konfiguracja jest banalna. Znowu to jedynie kilka minut i gotowe. Co jest fajne w sofcie to, to że sam soft jest open-source, dzięki czemu można pobrać obraz dockerowy, odpalić na naszym serwerze i nie musimy płacić za korzystanie z wersji SASS.

Docker - Kto zna ten pokochał, kto nie zna ten na pewno pokocha, szczególnie jeżeli do tej pory korzystał z Vagranta. Docker to narzędzie wirtualizujące środowisko developerskie jak i produkcyjne. Dające nam pewność, że każdy, czy to deweloper, czy też serwer produkcyjny będzie miało te same wersje narzędzi wykorzystywanych w nim. Mówię tu o nginx, php, mysql, mongo, redis i co tylko dusza zapragnie. Obecnie nie było by softu, które to po wpisaniu docker + szukane narzędzie w google nie znalazłoby obrazu z tym narzędziem. Docker daje nam także możliwość łatwego skalowania aplikacji oraz jej rozproszenia, co przy późniejszym sukcesie naszego produktu jest nieocenioną zaletą. Jeżeli interesuje Was konfiguracja podstawowego środowiska deweloperskiego zapraszam do obejrzenia mojego cyklu filmików na ten temat

VPS - Jako, że jesteśmy na etapie MVP, nie ma co szaleć z serwerem dlatego zdecydowałem się na tani vps w Ovh. 1 core, 2 GB RAM, 10GB SSD w zupełności wystarczą dla pierwszych klientów oraz przeprowadzeniu początkowych eksperymentów na produkcie oraz nie opróżnią naszej kieszeni (14 zł brutto). Mało tego jeżeli w przyszłości będziemy chcieli rozszerzyć naszą architekturę serwerową, obecny serwer możemy wykorzystać jako serwer testowy, natomiast na serwer produkcyjny możemy wykupić porządniejszą maszynę (200–500zł). Do tego Ovh ma w swojej ofercie możliwość wykupu serwerów CDN, backupu oraz sieci wewnętrznej, co już miałem możliwość przetestować w środowisku produkcyjnym i się nie zawiodłem. Ich SLA także nie jest złe, z mojego doświadczenia wynika, że awarie w Ovh to rzadkość, szczególnie w porównaniu z innymi serwerowniami, z którymi miałem do czynienia.