Konkurs Daj Się Poznać to jednak nie tylko pisanie bloga. To pisanie dwóch postów tygodniowo, z czego przynajmniej jeden jest o rozwijanym projekcie Open Source. Czyli, podkreślam, jednocześnie należy rozwijać jakiś projekt Open Source.

Ponieważ do tej pory jeszcze czegoś takiego nie robiłem, a nie mam żadnego pomysłu na jeszcze jednego liba, albo na jeszcze jeden framework, postanowiłem wystartować ze starterem aplikacji (boilerplatem) i dorzucić kamyczek do tych dziesiątek milionów (setek milionów?) repozytoriów na GitHubie. Tego typu projekty już kilka razy pozwalały mi szybko zacząć projekt i prawie od razu tworzyć business value. Szczególnie dobrze wspominam już raczej porzucony googlowy Web Starter Kit (kto w dzisiejszych JSach korzysta jeszcze z Gulpa? 😉), albo na przykład naszą firmową Bootzookę na Akka HTTP i Angularze 1.5.

Zaletą tej drugiej jest szczególnie to, że ma wbudowaną obsługę użytkowników (rejestracja, logowanie, przypominanie hasła itd.), co w zasadzie potrzebne jest w większości aplikacji. Stosunkowo pracochłonna funkcjonalność (nawet przy wsparciu libów), tutaj dostępna jest out of the box, dzięki czemu znacznie szybciej można zacząć implementować coś konkretniejszego. Mój starter zdecydowanie będzie miał wbudowane zarządzanie kontem użytkownika.

Po drugie, mój starter nie będzie miał backendu.

Obecnie chyba większość aplikacji webowych tworzy się w taki sposób, że mamy rozdzielony backend i frontend. Backend jest w Scali, Javie, Pythonie, Rubym, Node.js, czy też czymkolwiek innym, a front w JavaScripcie, albo jakiejś pochodnej. Skutek tego taki, że trzeba utrzymywać dwa całkiem różne środowiska i dbać o to, by mogły się ze sobą komunikować. W pewnym sensie to tak, jakbyśmy mieli dwa bardzo silnie powiązane ze sobą komponenty i nie mogli nic zrobić, żeby osłabić te powiązania. Utrzymywanie takich dwóch komponentów to hardkor, prawda?

Jeśli chcesz dodać nową funkcjonalność do takiego systemu, to musisz zaimplementować logikę biznesową zarówno we froncie, jak i w backendzie, walidację musisz obsłużyć i tam, i tam, podobnie testy na froncie i na backendzie, a jeszcze przydałoby się pewnie coś naklepać w Selenium, żeby sprawdzić, czy wszystko razem ze sobą dobrze działa. Mnóstwo roboty.

Potem jeszcze kwestie DevOps – deployment dwóch środowisk, sharding baz danych, load balancing itd. Jeśli aplikacja ma tylko front, to wystarczy że kod źródłowy zostanie zbudowany jakimś Webpackiem z babelami i spółką, a potem to wszystko można wrzucić na zwykły hosting. Żadnego Heroku, czy własnych serwerów aplikacji.

(Na marginesie: oczywiście wiem, że backendy mają swoje zalety i często nie da się bez nich obejść… jednak może nie tak często, jak się może wydawać).

W pewnym sensie będzie mój starter będzie gdzieś miał backend, bo te dane użytkownika trzeba gdzieś trzymać. Tyle, że nie ja będę go utrzymywać. Do zarządzania użytkownikami mam zamiar wykorzystać usługę Amazon Cognito, której ostatnio miałem okazję trochę liznąć i byłem pod dużym wrażeniem. W starterze pewnie tego jeszcze nie będzie, ale w apkach zbudowanych na nim do przechowywania danych skorzystałbym pewnie z S3 albo DynamoDB, a do ich obróbki z AWS Lambdy. Wszystko po to, by uniknąć swojego backendu i żeby aplikacja była w serverless architecture.

Głównym powodem, dla którego chcę to zrobić właśnie w taki sposób, jest oszczędność czasu. Kiedy chcę szybko wystartować z jakiś projektem (zwłaszcza takim lekkim), szkoda mi czasu na pisanie backendu i zajmowanie się tymi wszystkimi zagadnieniami wokół utrzymania środowiska.

Po trzecie wreszcie, uważam, że to jest dobry moment, żeby się czegoś nauczyć. W tym wypadku – wejść w ekosystem Reacta.

Do tej pory, jeśli chodzi o front, robiłem sporo aplikacji z Bootstrapem i Angularem 1.x. Podejrzewam, że Angular 1.x będzie się coraz bardziej starzeć, a z kolei Angular 2 to dla mnie taki trochę znany z branży muzycznej “syndrom drugiej płyty”. Innymi słowy, wydaje mi się, że twórcy trochę przedobrzyli i nie przyjmie się tak dobrze jak jedynka. Dlatego też nie zamierzam się uczyć nowego Angulara w najbliższej przyszłości (trójki, czwórki i dziesiątki też na razie nie). Przez jakiś czas zastanawiałem się, czy nie wchodzić w Vue.js (mniej więcej w tym czasie, kiedy wyszła 2 i GitLab się tak chwalił, że korzystają z Vue), jednak ostatecznie zdecydowałem się na Reacta. A żeby jeszcze dodać wisienkę do tego tortu, to zamiast Bootstrapa będzie pewnie Material Design.

Innymi słowy, w ramach tego konkursu chciałbym stworzyć taki starter dla startupów. Jeśli chcesz szybko zacząć od czegoś małego, ale potencjalnie skalowalnego, to właśnie ten projekt może być dla Ciebie.