pokaż komentarz
@Lisekchytrusek: dalej zero konkretów. to pozwól że ja Ci napiszę jak to wygląda na backendzie:
- ważny jest storage - nie zawsze najlepszy jest RDBMs, czasmi warto pójść w NoSQL, czasami natomiast ważne jest to by zmieszać ze soba jedno i drugie podejście
- część systemów moze wymagać podejścia bazowanego na przechowywaniu wszystkich eventów, wtedy równeż warto pomyśleć nad innym storage'em do zbierania eventów, innym do wyciągania danych
- normalizacja danych (w przypadku RDBMs) nie zawsze jest najlepszym wyjściem - często ważna jest optymmalizacja pod konkretny tryb pracy aplikacji
- ważne bywa również przemyślenie to w jaki sposób będziemy dystybuować dane - jak będziemy skalować - skalowanie vertykalne praktycznie nigdy nie jest dobrym wyborem. horyzontalne - tu jest wiele podejść, wiele technik
^ to wszystko to sam storage
potem budujemy serwer, może być nam potrzebne:
- coś do cachowania zapytań (memcached, redis)
- kolejka (pytanie jaka - bo tych jest kilka rodzajów)
- czy dane będziemy serwować tylko w za pomocą API REST? a może za pomocą GraphQL? a może w jeszcze inny sposób? może część systemów będziemy chcieli powiadamiać jak tylko coś się zmieni?
- czy musimy się integrować z innym systemem? może należy wykonać jakieś operacje ETL? cyklicznie?
- czy budyjemy monolit, czy rozbijamy system na mikroserwisy? jakie? ile? czy na pewno mamy w zespole kompetencje do pracy w środowisku asynchronicznych mikroserwisów? jak będziemy je testować? czy faktycznie będą od siebie niezależne?
- jeśli system będzie rozproszony to jakiego podejścia zechcemy użyć? może Elixira/Erlanga z ich systemem aktorowym? a może Akki? może oprzemy się na kubernetesie jednak i na chmurze jakiegoś usługodawcy?
a to dopiero sam początek. praktycznie nic nie pisałem o frameworkach, językach etc. (poza Erlangiem i Elixirem na sam koniec).
jak to wygąda w przypadku frontu:?
- język? pewnie raczej TypeScript
- framework/biblioteka: Vue/Angular/React. za cokolwiek bardziej egzotycznego raczej nikt się nie bierze.
- i teraz pytanie jakie wielkie pytanie na Ciebie nadal czekają w tym momencie? co też niesamowicie ważnego musisz obmyśleć? jakie to decyzje zostają do dyspozycji zespołu frontendowego?
- czyżbyście to właśnie WY rozmawiali z analitykiem biznesowym na temat PROCESÓW? nie. co najwyżej można rozmawiać z uzytkownikami na temat uzyteczności UI - tutaj pełna zgoda.
pewnie że pojawiają się jakieś nowsze podejścia typu: Svelte (tak, pisałem w tym) czy też ogólnie micro-frontends, ale to nadal nie adresuje tego o czym pisałem wyżej. we froncie po prostu ogrom problemów NIE istnieje i tyle.
oczywiście że można też wybrać sobie inny język niż JavaScript czy TypeScript, ale na froncie ma to w sumie drugorzędne znaczenie - wszystko i tak w koncu jest transpilowane do JS (czyli działa na tej samej maszynie uruchomieniowej).
(upraszczam front, bo nie chce mi się pisać, poza tym, to nie ja mam bronić tej niszy).
oczywiście z frontu wyrzucam WebAssembly - bo to zupełnie co innego. wyrzucam też wszelkie rozwiązania typu "immediate GUI" - czyli wszystko to co pisane jest WebGL etc. bo to bardziej rozwiązania typu wizualizacje.
tak jak pisałem wyżej nie podałeś żadnych konkretów, a teksty w stylu "wystarczy wyszukać" albo "jakbyś pracował" są trochę słabe. nie chodzi mi o możliwości. front jest po prosty NUDNY z perspektywy kogoś kto lubi rozwiązywać problemy.
chciałbym w jakiś kulturalny i merytoryczny sposób porozmawiać na ten temat - bo ja swoje zdanie bazuję na własnym doświadczeniu w IT, oglądaniu od środka wielu projektów i konkretnych doświadczeń z tym związanych.
