Jaki projekt do portfolio frontend/Javascript

A back-end mozna zaserwowac razem z frontem, wiesz? xd

Chciałem stworzyć jakiś serwis, gdzie użytkownicy mogą się w czasie rzeczywistym komunikować,
dostęp do publicznego czatu itp. w node.js, ale doszedłem do wniosku że to backend i chyba to nie jest odpowidni pomysł,

Znajomość Node.js to zaleta nawet przy frontendzie.

Facet. Jak czujesz się na siłach pisać back-end to zrób i ten czat jeśli chcesz. Jest o to tyle lepszy temat, że nie będzie to kolejnym CRUD'em. Możesz zrobić do tego prostą rejestracją, avatary, jakiś prosty profil do tego komunikacja real-time. I masz bardzo duże pole do budowania frontu.

Edit:
React i NodeJS pasują do siebie z tego co mi wiadomo. Kolega napisał w obu projekt i jest zadowolony, a pracuje jako JS Dev z naciskiem na robotę frontu w React.

Tworzysz sobie sztuczne ograniczenia. Możesz robić, co chcesz i jak chcesz.

Myślę, że większe wrażenie zrobi jeden projekt naprawdę dobrze zrobiony pod kątem całości (cokolwiek, albo super czat, na miarę Slacka, albo super zrobiony sklep) niż kilka projektów, które zrobiłeś na pół gwizdka.

Poza tym - w pracy często pracuje się z większymi długotrwałymi projektami + przykłada się uwagę do szczegółów, więc rozwijanie większego projektu + robienie go porządnie, ładnie, z myśleniem o detalach itp. to może być cenna lekcja. Bo mam wrażenie, że to, co teraz robisz, to trochę na pół gwizdka, tak jakbyś traktował projekty instrumentalnie - czyli tak jakbyś wcale nie chciał robić tego czatu, czy sklepu, a chciałbyś go zrobić tylko po to, żeby mieć coś z Node/frontendem do portfolio. Tyle, że nie jest to właściwe podejście, bo w pracy to wymagania biznesowe są zwykle ważniejsze od technologii. To produkt jest ważny, i dopiero pod tym kątem dobiera się technologie.

LukeJL napisał(a):

'tylko po to, żeby mieć coś z Node/frontendem do portfolio. Tyle, że nie jest to właściwe podejście, bo w pracy to wymagania biznesowe są zwykle ważniejsze od technologii. To produkt jest ważny, i dopiero pod tym kątem dobiera się technologie.'

No właśnie, ale jak się ma zapytywanie bazy danych mongodb do pracy jako frontendowiec, o to mi głównie chodzi.
Bo przy takim projekcie to najwęcej pracy jest w backendzie. I teogo się najwięcej nauczę.

edicik..
dajmy na to taki slack, najwięcej czasu przejdzie mi na obsługę socket.io niż js, czy reacta.

Zrób np. jakąś interaktywną animację w 3D.

Dobra, przestaje narzekać, wezmę się do roboty.
PS. widział ktoś jakiś tutorial do range w js?
PS2. aha, dziękuję za pomoc.xd

No właśnie, ale jak się ma zapytywanie bazy danych mongodb do pracy jako frontendowiec, o to mi głównie chodzi.

Ja będąc frontendowcem z zamiłowania pierwszą pracę zdobyłem właśnie przy Node.js + Mongo + parę innych rzeczy (i musiałem się w biegu uczyć tych technologii). Co ciekawe w zdobyciu tej pracy pomogło mi to, że miałem w swoim portfolio... grę przeglądarkową ze skaczącym kotem (w zasadzie tylko 1-szy level gry, bo tylko tyle udało mi się zrobić). Okazało się, że to czym miałem się zajmować (branża finansowa) miało nieco wspólnego z robieniem gier (podobne wzorce projektowe).

Anyway, niepotrzebnie się szufladkujesz, bo "wszystko jest jednym".

No chyba, że nie lubisz backendu i chcesz od niego uciec jak najdalej, żeby tylko go nie widzieć na oczy.

edicik..
dajmy na to taki slack, najwięcej czasu przejdzie mi na obsługę socket.io niż js, czy reacta.

Skąd wiesz? Próbowałeś coś takiego zrobić (choćby prototyp)?

Czytając to, co piszesz, mam wrażenie, że próbujesz na siłę zrobić z siebie frontendowca, mimo, że ciągnie cię do backendu (teksty typu przy takim projekcie to najwęcej pracy jest w backendzie. czy Rejestracja, koszyk, zamówienia, płatność. No i dupa bladaa., wszytko backend. i ogólnie lekceważenie strony frontendowej są typowe raczej dla backendowców. Frontendowiec by się zastanawiał:

• jak podzielić apkę na komponenty,
• jak zrobić komunikację z serwerem w elegancki sposób (zachowując separation of concerns)
• jak sprawić, żeby komponenty same się odświeżały, kiedy będzie taka potrzeba
• w jaki sposób trzymać i aktualizować dane po stronie klienta (zarówno te w pamięci RAM, jak i te zapisane np. w localStorage)
  dwa (a być może nawet trzy) ostatnie punkty to powód, dla którego ludzie używają takich rzeczy jak Redux czy Mobx albo Rx. A zobacz, jak wiele się o tym mówi w świecie frontendu)
• jak podejść do kwestii testowania
• skąd wziąć ikonki, które zapewne będą potrzebne w takiej aplikacji
• jak zrobić fajny, responsywny layout
• jakich narzędzi dodatkowych użyć, czy może w ogóle nie używać (np. czy użyć frameworka CSS czy pisać samemu cały CSS)
• jak ogólnie pisać CSS (goły CSS? Sass? CSS Modules? )
• jak zrobić fajne animacje (chociaż przy użyciu frameworka CSS jest szansa, że już one będą).
• jak obsłużyć starsze przeglądarki, czy w ogóle nie obsługiwać
• co z obsługą Markdown? Pewnie musiałbyś znaleźć dodatkową bibliotekę i ją zintegrować z czatem.
• jak zrobić upload plików za pomocą drag'n'drop
• jak zrobić obsługę czasu (rzeczy typu 5 minut temu). Nawet używając gotowej biblioteki, to musisz ją znaleźć i wyczytać, jak to się robi.
• jak zrobić kilka wersji językowych w aplikacji
• co z obsługą mikrofonu? Video? Zaawansowane czaty miewają taką opcję.

Oczywiście, te wszystkie rzeczy są niepotrzebne, jeśli piszesz tylko proof-of-concept - wtedy nie ma co kombinować, tylko zrobić najmniejszą rzecz, która działa. Zrobienie frontendu na zasadzie goły HTML + Socket.io jest okej, jeśli chcesz zrobić tylko "coś, co działa.". Ale jak chcesz napisać aplikację, która mogła już by pójść na produkcję, to strona frontendowa wcale nie będzie taka hop-siup. Nawet jeśli część z tych problemów łatwo będzie rozwiązać (np. ikonki - znajdujesz bibliotekę darmowych ikonek i ściągasz), to część nie będzie taka i okaże się, że nad pewnymi rzeczami we frontendzie będziesz siedział i się zastanawiał, jak zrobić. Poza tym nawet rozwiązywanie wielu mniejszych problemów też zajmuje czas.

Czyli zastanów się, co chcesz zrobić i po co. Może faktycznie chcesz zrobić tylko proof-of-concept, a nie kompletną aplikację. Może więc lepiej nie robić całej aplikacji, ale właśnie - jakąś animację we frontendzie, jak wspomniała @Freja Draco?

no wiem... bliżej mi do backendu, bo na studiach jest tylko backend. Frontu to ja na nich nie ujrzałem.
o z tą 5 min temu to tragedia była xd... robiłem już coś takeigo, ale narzędzi nie znałem, i pewnie dlatego nic z tego nie wyszło....

Słyszałeś o czymś takim jak mock? Napisz sobie jakiegoś durnego klienta API, który nawet nie komunikuje się z backendem albo użyj jakiegoś firebase’a i masz problem z głowy.