Projekt w ramach nauki

0

Hej,
planuje w ramach nauki paru technologii, które chciałem poznać stworzyć bardziej złożony projekt, chciałbym Was prosić o konstruktywną krytykę jeśli chodzi o dobór technologii/narzędzi.

Sam pomysł na aplikacje jest jeszcze inprogress, na ten moment myślałem o aplikacji do zarządzania finansami, ale z taką to wiadomo, że nikt z tego nie będzie korzystać z wielu względów (chociażby takich, że nie zintegruje tego z żadnymi aplikacjami bankowymi, nie będzie to apka mobilna i trzeba dużo pisać i uzupełniać).

Chciałem się do tego zabrać tak porządnie, tzn. zanim usiądę w ogóle do kodu to będę to wszystko rozplanowywać, diagramy komponentów etc., projektować prototypy/mockupy, później rozpisywać backlog (sprintów nie będzie, będzie kanban XD)

inb4: wiem, że to będzie bardzo duży overengineering, ale tak jak pisałem robię to tylko w ramach nauki

No więc:

  • Planuje stworzyć monorepo przy pomocy nx i yarn workspaces,

  • Po stronie klienta chce wykorzystać:

  • Po stronie serwera chce wykorzystać:

    • Node.js
    • NestJS i API GraphQL

  • DB:

    • mongoDB stojące jako kontener dockerowy

Założenia jakie sobie przyjąłem:

  • Zrobić najlepszy DX (developer experience) jaki się tylko da:
    • lintery,
    • odpalanie husky i sprawdzanie linterów etc. przy każdym commicie
    • automatyzacja różnych procesów za pomocą github actions takich jak testy / deploy po mergu do odpowiedniego brancha i po przejsciu testów
  • Zrobić SSO login za pomocą google/facebooka i fajnie by było też apple, ale z tego co się orientowałem to dużo zachodu z tym ( i tu się zastanawiam czy nie iść na "łatwizne" i wykorzystać firebase jedynie do autentykacji i niczego więcej w apce - czy to dobra praktyka czy srogie nadużycie?)
  • Chce mieć w aplikacji panel administratora do sprawdzania różnych statystyk z apki i możliwością zarządzania użytkownikami:
    • (bany / usuwanie kont / zmiana rodzaju konta - dostęp do większej ilości funkcjonalności - takie różne poziomy konta premium)
    • wykresiki XD poznałem ChartJS i mi się tak spodobała, że chce się nimi pobawić
  • Chce mieć i18n i możliwość zmiany języka (NextJS to bardzo fajnie oferuje i znalazłem dwa przydatne narzędzia i18next i i18nexus )
  • Chciałem też wykorzystać CMS do wyświetlania różnych większych ilości tekstu i z tego co patrzyłem to Storyblok też zapewnia i18n, ale to już będzie nieco przesada xD i za dużo źródeł prawdy
  • Pisanie unit testów
  • Sentry do monitorowania błędów

I to chyba tyle na ten moment, proszę o rady/uwagi, dzięki.

PS. Jeśli post jest umieszczony w złej kategorii to proszę o przeniesienie, tak samo z tagami jeśli jakichś nadużyłem to proszę o usunięcie/dodanie.

PSS. Planowałem wrzucać tu update na random czy gdzieś indziej gdzie by to pasowało i założyć swój tag do czarnolistowania (o ile jest w ogóle taka możliwość?), ale nie widzę możliwości stworzenia własnego tagu.

2
RegalWK napisał(a):

Hej,
planuje w ramach nauki paru technologii, które chciałem poznać stworzyć bardziej złożony projekt, chciałbym Was prosić o konstruktywną krytykę jeśli chodzi o dobór technologii/narzędzi.

Pytanie, czy chcesz się uczyć technologii, czy zrobić apkę. Bo ja to widzę tak, że mija np. miesiąc i się okazuje, że twoja apka nic nie robi praktycznie, bo przez cały miesiąc stawiałeś infrastrukturę. Chociaż z drugiej strony - nauczysz się z tuzina różnych technologii, więc jeśli twoim celem jest nauka technologii na apce, którą i tak wyrzucisz - to spoko.

Jednak jeśli byś chciał bardziej na poważnie podejść do samego tworzenia projektu, to lepiej byłoby skupić się na tym, co apka ma robić i zrobić najpierw coś działającego, a później dorzucać technologie.

NestJS i API GraphQL

a np. ani Nest ani GraphQL nie jest potrzebne, żeby zrobić prostą apkę. Nawet jak chcesz użyć tego na późniejszym etapie, to nie znaczy, że musisz stawiać już projekt od razu używając jakichś zmyślnych technologii.

inb4: wiem, że to będzie bardzo duży overengineering, ale tak jak pisałem robię to tylko w ramach nauki

No właśnie zależy nauki czego. Bo jeśli twoim celem jest nauka technologii, to nawet dobry plan, żeby używać maksymalnej liczby technologii.

Jednak nie jest to dobry sposób nauki robienia projektów na serio.

Chciałem się do tego zabrać tak porządnie, tzn. zanim usiądę w ogóle do kodu to będę to wszystko rozplanowywać, diagramy komponentów etc., projektować prototypy/mockupy, później rozpisywać backlog (sprintów nie będzie, będzie kanban XD)

Takie podejście dobre jest na dwa tygodnie. A co dalej? Mnóstwo projektów zaczyna się tak, że ludzie sobie wszystko planują, projektują, rozpisują wszystko co do joty. I przez kilka tygodni nawet można tak pisać. Potem się zaczynają problemy. Genialny plan okazuje się nie taki genialny i piękny kod zaczyna się rozjeżdżać i wcale już nie jest taki piękny, jest coraz więcej entropii i robienia rzeczy naokoło.

Dlatego wymyślono Agile, extreme programming, czy inne zwinne metodyki, które zakładają ciągłą ewolucję zamiast planowania wszystkiego od zera.

Co prawda sama czynność planowania może być całkiem przydatna, problem zaczyna się, jak przestajesz mieć kontakt z rzeczywistością i wydaje ci się, że jesteś w stanie zaplanować coś dobrze i masz superoptymizm i nie jesteś elastyczny w modyfikacjach. W twoim poście widzę właśnie taki super-optymizm - powrzucać masę technologii do projektu na zapas, nawet jak nie są jeszcze potrzebne (jeśli jeszcze nie znasz dobrze tych technologii, to jest to dodatkowy problem).

Takie apki zwykle kończą się jakimś big ball of mud (czyli miało być pięknie, a i tak wychodzi chaos) albo przeinżynierowaniem (jak ktoś nie umie wpuścić chaosu i na siłę się trzyma pierwotnych wytycznych, które się zdezaktualizowały i później architektura jest już postawiona, kompletnie nieadekwatna, ale zamiast ją uprościć, to ludzie ją jeszcze bardziej komplikują).

2

Tak sobie mysle -> a gdybys sprobowal najpierw zaprojektowac jak bedzie wygladal UI bo IMHO za mocno sie skupiuasz na engineeringu wokol projektu i tym sposobem zrobisz cos co bedzie fajne dla deva, ale bez sensu dla usera?

@Miang: jesli chodzi o oagrumenty przeciw Mongo polecam prezentacje:

Co do wyboru DB -> w projekcie robionym dla zabawy nie ma znaczenia. W prawdziwych systemach wchodza takie tematy jak: wydajnosc, SLA, bezpieczenstwo, upgrade do nowszej wersji, migracja danych i tak naprawde dopiero wtedy zaczyna sie prawdziwa zabawa, ale o tym tutoriale nie wspominaja. Rowniez skala ma znaczenie, inaczej zarzadza sie uslugami ktore maja kilka nodow, a inaczej takimi ktore maja kilkaset. Dochodzi backup/restore, disaster recovery, High availability itp.

1 użytkowników online, w tym zalogowanych: 0, gości: 1