Projekt aplikacji pod kątem frontendu

[kamilwil]

• [x] prototyp w Figmie link do prototypu

• [x] one-page vs multi-page (multi-page, początkowo jeden statyczny HTML na landing page i drugi HTML z wstrzykiwaniem JS-a na widok zalogowanego)

• [x] statycznie vs dynamicznie generowana zawartość HTML-a (statycznie + client-side rendering)

• [x] samodzielne tworzenie HTML-a vs korzystanie z gotowych narzędzi/szablonów (samodzielny szkielet + biblioteki kontenerów/kontrolek (np. Bootstrap))

• [x] widok dla niezalogowanego użytkownika vs widok dla zalogowanego użytkownika (patrz prototyp)

[KarolNiem]

one-page vs multi-page: one-page - wszystkie informacje znajdują się na stronie podzielonej na poszczególne sekcje.

Korzyści płynące z podejścia one-page:

• wygląd aplikacji jest nowoczesny i przykuwający uwagę.
• większy potencjał przy ewentualnym przenoszeniu aplikacji na urządzenia mobilne.

Zalety podejścia one-page:

• prosta nawigacja - brak linków, a jedynie odnośniki do poszczególnych sekcji strony.
• lepsze doświadczenie na urządzeniach mobilnych (z punktu widzenia ewentualnego przejścia na urządzenia mobilne w przyszłości).
• nadaje się do aplikacji, których zadaniem jest prezentowanie prostych, łatwo przyswajalnych treści
• łatwość w utrzymaniu - ze względu na brak linków do innych stron co wpływa na fakt, że detekcja i rozwiązywanie problemów jest łatwiejsze
• łatwość w utrzymaniu uwagi użytkownika odwiedzającego stronę

Wady podejścia one-page:

• trudności w skalowaniu.
• potencjalne problemy z pozycjonowaniem w Google, ze względu na małą liczbę słów kluczowych, które możemy umieścić w zwięzłym tekście (SEO).

multi-page - aplikacja podzielona jest na grupę powiązanych ze sobą stron, do których dostać można się klikając w odpowiednie odnośniki.

Korzyści płynące z podejścia multi-page:

• Zapewnia większą swobodę w organizacji informacji dzięki czemu bardziej nadaje się do rozbudowanych aplikacji.

Zalety podejścia multi-page:

• Tradycyjny sposób nawigacji.
• brak istotnych ograniczeń w kwestii skalowania.
• Lepsze pozycjonowanie strony.

Wady podejścia multi-page:

• konieczność ciągłego utrzymywania strony.
• trudności w utrzymaniu uwagi użytkownika ze względu na dużą ilość

Które podejście powinniśmy wybrać? Według mnie powinniśmy zastosować podejście one-page ze względu na to, że przekazywać chcemy stosunkowo małą ilość informacji w prostej formie graficznej (wykresy, badge, kafelki) z małą ilością tekstu (statystyki kontrybucji z ewentualnym krótkim opisem). Stronę moglibyśmy podzielić na sekcje takie jak: wstęp, w którym umieścilibyśmy nazwę naszej aplikacji, 2-3 zdania krótkiego opisu (albo jakiegoś hasła reklamowego). jakieś obrazki w tle. Poniżej przykład:

Następna sekcja dotyczyłaby profilu programisty ze zbiorczymi statystykami ze wszystkich jego repozytoriów. Można by to było zrobić w prostym formacie: lewa połowa ekranu - krótki opis, prawa połowa ekranu - wykres, następna informacja: lewa połowa ekranu - wykres, prawa połowa ekranu - opis i tak na zmianę, tak jak jest to zrobione np tutaj:

Poniżej zrobiłbym w podobnym stylu kolejną sekcję dotyczącą panelu ze statystykami kontrybucji. Na koniec można by było dodać jakąś sekcję zamykającą. W przykładzie poniżej jest to filmik reklamowy z formularzem kontaktowym, u nas nie jestem pewien co mogłoby to takiego być.

Oczywiście pozostaje pytanie czy podejście multi-page nie byłoby dla nas łatwiejsze ze względu na to, że jest bardziej klasyczne i łatwiej znaleźć na internecie wskazówki co do projektowania strony w takim podejściu.

[KarolNiem]

Dynamicznie vs statycznie generowana zawartość HTML-a: Strona dynamiczna - jest to rodzaj strony internetowej, której treści mogą się zmieniać w zależności od konfiguracji, na przykład: wyboru przeglądarki, rodzaju urządzenia, na którym się ją otwiera, strefy czasowej, pory dnia oraz innych czynników, pozwala ona także na dwukierunkową komunikację z użytkownikami. Strony dynamiczne oferują 3 typy generowania treści:

• kody wykonywany po stronie klienta - zawartość strony pochodzi z lokalnego komputera klienta. Dotyczy stron, w których zmiany wprowadzane są w odpowiedzi na takie działania, jak kliknięcie myszy czy klawiszy klawiatury.
• Kod wykonywany po stronie serwera - zawartość strony tworzona jest na serwerze www, po czym jest pobierana i wyświetlana przez przeglądarkę.
• Kod kombinowany - łączące skrypty po stronie klienta oraz po stronie serwera. Pozwala ograniczyć obciążenia i zoptymalizować stronę.

Zalety podejścia dynamicznego:

• łatwiejsze i szybsze aktualizacje, jak również wprowadzanie nowych treści
• większa interakcja z użytkownikami
• większa funkcjonalność (np. strony e-commerce, portale z opcją logowania)
• większe możliwości, bardziej atrakcyjna i angażująca dla użytkowników

Wady podejścia dynamicznego:

• bardziej złożona pod względem konfigurowania i wdrożenia
• wolniejszy czas ładowania strony
• droższa w wykonaniu oraz utrzymaniu

Strona statyczna - zakodowana głównie w języku HTML i wyświetla te same informacje każdemu użytkownikowi, nie wymaga tworzenia baz danych.

Zalety podejścia statycznego:

• większe bezpieczeństwo strony, ponieważ nie ma zaplecza po stronie serwera
• mniej zależności lub nawet ich brak, jeśli chodzi o zewnętrzne system
• szybkość
• oszczędność - koszty wykonania strony są niewielkie
• łatwość zintegrowania, np. formularza czy płatności i skalowania strony
• jej utworzenie nie wymaga wielkich umiejętności technicznych czy programistycznych

Wady podejścia statycznego:

• brak systemu CMS, wymaga aktualizacji i zmian od programisty
• nie wyświetla dynamicznych treści użytkownikom
• mniej angażująca i atrakcyjna dla użytkowników

Które podejście należy wybrać? Moim zdaniem naturalne jest tutaj podejście dynamiczne ze względu na to, że tworzymy stronę wyświetlającą różne informacje dla różnych użytkowników, implementujemy w niej opcję logowania. Kod strony powinien być tworzony po stronie serwera i być pobierany i wyświetlany przez przeglądarkę.

[KarolNiem]

Samodzielne tworzenie HTML-a vs korzystanie z gotowych narzędzi/szablonów: Oba podejścia mogłyby być dobre ze względu na to, że nie tworzymy bardzo rozbudowanej aplikacji. Ja skłaniałbym się ku wykorzystaniu gotowych szablonów z bootstrapa. Na pewno jest sporo darmowych szablonów, dedykowanych pod strony one-page, można je znaleźć (albo wzorować się na nich) np tutaj:

• https://onepagelove.com/templates/free-templates/page/2
• https://startbootstrap.com/themes/landing-pages
• https://webdesign.tutsplus.com/articles/bootstrap-single-page-templates-for-landing-pages--cms-39401
• https://nicepage.com/one-page-template
• https://colorlib.com/wp/cat/one-page/

[mpfmorawski]

Moje wstępne uwagi na tym etapie:

one-page vs multi-page

Przy wyborze one-page pierwsze, co rzuca mi się w oczy, to (nawet wspomniana) trudność w skalowaniu. A to z kolei skalowalność powinna być (patrząc chociażby na nazwę przedmiotu) dla nas ważnym aspektem. Z drugiej strony rozpisane przez nas funkcjonalności pasują bardziej na one-page

statyczne vs dynamiczne

Dynamiczne generowanie brzmi faktycznie atrakcyjnie. Trzeba jednak pamiętać, że takie podejście będzie się wiązało z większym nakładem pracy, żeby wykazać, że nasz system jest niezwodny (co jest kolejnym hasłem w nazwie naszego przedmiotu, czyli reliable)

samodzielne tworzenie vs szablony

Gotowe szablony myślę, że są w takim kontekście naturalnym rozwiązaniem. Ważne jednak tutaj, że nie na wszystkie nasze grafiki znajdziemy od razu template (patrz chociażby na nasze specyficzne wykresy).

[pktiuk]

Zaczynając od porównania one-page vs multi-page. Wygląda jakby było to skądś przeklejone. Argumenty nie są przefiltrowane pod względem użyteczności dla naszego projektu. (nie wspominając o tym, że część jest niewłaściwa). Np. to, czy wygląd przykuwa uwagę nie zależy od tego, czy to jest one-page, lecz od ogólnego designu, zaś profilowanie przez googla nie ma dla nas znaczenia. Jak rozumiane jest tutaj skalowanie strony?

Propozycja wyglądu: W żaden sposób nie jest zaznaczone jak ma wyglądać witryna dla osoby niezalogowanej
Czy aby na pewno chcemy każdemu zalogowanemu użytkownikowi pokazywać wstęp, który opisuje co robi nasza strona?
Model, na którym bazujesz przy opisie to bardziej strona wizytówkowa, niż użytkowa.
W naszym projekcie taką "wizytówkę" moglibyśmy serwować niezalogowanym użytkownikom, a po zalogowaniu możliwe byłoby ujrzenie części użytkowej (czyli statystyki)

Strona generowana statycznie i dynamicznie
Zamiast porównać sposoby generowania stron: generowane statycznie i generowane dynamicznie porównane zostały 2 rodzaje stron (statyczne vs dynamiczne)

[kamilwil]

Ten temat to dla mnie póki co studnia bez dna. :D Duża dawka nowej wiedzy w krótkim czasie, teraz trzeba to jakoś uporządkować...

Ogólna koncepcja: Myślę, że dla mnie jako osoby, która z webowym frontem nie miała wcześniej zbyt dużo do czynienia, najlepiej byłoby zminimalizować liczbę logicznie rozdzielnych części, aby łatwiej było się odnaleźć w projekcie. Dlatego chciałbym zaproponować, żeby projektowanie i implementacja odbywało się ze względu na trzy widoki:

• widok dla niezalogowanego użytkownika
• panel logowania i rejestracji
• widok dla zalogowanego użytkownika

Uważam, że pierwsze dwa mogą mieć stały layout - niezalogowany użytkownik zobaczy "wizytówkę", a logujący/rejestrujący się zobaczy jeden z dwóch formularzy. Trzeci widok będzie miał zmienne treści, ale powinien mieć domyślnie możliwie niezmienny layout wypełniany tylko odpowiednimi danymi. Zmienność powinna wynikać tutaj jedynie z personalizacji, ale chyba nie w każdym podejściu będzie to tak samo łatwe.

Statyczna strona: Ze względu na to, że pokazywane dane zależą od zalogowanego użytkownika, całkowicie statyczna strona odpada. Można dynamicznie tworzyć statyczne strony na bazie wypełniania szablonów HTML (Static Site Generators), ale to podejście wydaje się za bardzo skomplikowane jak na naszą stosunkowo prostą apkę.

Jeśli idziemy w Single Page Application, to zakładamy:

• client-side rendering,
• pobieranie "szkieletowego" HTML-a, który jest wypełniany danymi (np. pobieranymi po AJAX-ie) po stronie klienta,
• dłuższy czas ładowania na początku i płynniejszą nawigację po stronie potem,
• możliwość wyświetlenia zawartości dopiero po pełnym załadowaniu JS-a (ale wtedy od razu z pełną interakcją) - taki biały ekran przez dłuższy czas może być wnerwiający dla użytkownika,
• wykorzystanie mechanizmu code splitting (wykonanie kodu dla poszczególnych części strony), jeśli czas początkowego ładowania okaże się tragiczny,
• możliwie małą zmienność w widoku zalogowanego, żeby nie tworzyć zbyt wielu wariantów tego samego widoku, które trzeba by przechowywać w pamięci i ładować przy starcie strony,
• preferowane okna dialogowe zamiast osobnych pełnych widoków,
• brak zapisywania "historii", ale w takim układzie w naszej apce niekoniecznie byłoby to przydatne,
• oddzielenie logowania/rejestracji do osobnej strony dla bezpieczeństwa, tylko nie wiem czy odpowiednio skonfigurowany routing tutaj wystarczy, czy potrzebny byłby osobny HTML
• ograniczoną odporność na XSS i inne ataki,
• większą wrażliwość na wydajność urządzeń oraz stabilność połączenia u użytkownika końcowego,
• większą niezależność na linii frontend<->backend, bo frontend tylko robi calle do API.

Jeśli idziemy w Multi Page Application, to zakładamy:

• server-side rendering,
• pobieranie gotowych HTML-i i pobieranie po AJAX-ie tylko danych ściśle związanych z konkretnym użytkownikiem do wypełnienia JS-em,
• krótszy czas ładowania na początku, ale przerwy na przeładowanie strony potem,
• wyświetlanie zawartości bez możliwości interakcji przed pełnym załadowaniem JS-a - moim zdaniem może to być mylące dla użytkownika,
• możliwość personalizacji w widoku zalogowanego, ale raczej nie w czasie rzeczywistym, tylko z przeładowaniem,
• preferowane osobne pełne widoki zamiast okien dialogowych,
• brak możliwości wykorzystania CDN, ale czy w ogóle rozważamy?
• większą odporność na XSS i inne ataki oraz słabość sprzętu/połączenia po stronie end usera - potencjalnie przydatne ze względu na "Reliable" w nazwie przedmiotu ;) ,
• ciągłą współpracę na linii frontend<->backend, choćby ze względu na dodatkowy mikroserwis (#1).

Inne kombinacje: Da się zrobić server-side rendering w Single Page Application, ale setup jest bardziej skomplikowany i wymaga osobnego frameworka, co komplikuje development i będzie prawdopodobnie zajmowało jeszcze więcej pamięci przy pierwszym ładowaniu SPA (przykład: Nuxt.js do Vue.js). Z kolei client-side rendering w Multi Page Application nie wydaje się mieć żadnych korzyści względem innych kombinacji i nie znalazłem raczej materiałów o takim rozwiązaniu.

Podsumowanie: Wydaje się, że Single Page Application miałoby sens przy tych założeniach, które mamy, ale z zastrzeżeniem, aby w jakiś sposób oddzielić we froncie kwestie logowania lub rejestracji od reszty aplikacji. Takie rozwiązanie uprościłoby też architekturę, bo frontend mógłby powstawać w dużej mierze oddzielnie od backendu i nie byłby potrzebny dodatkowy mikroserwis. Myślę, że kwestia wydłużonego czasu ładowania na początku też nie będzie w tym przypadku deal-breakerem (o ile to nie będzie trwało kilkanaście sekund za każdym razem), a dzięki temu można mieć płynną nawigację i responsywne UI.

Problem może być natomiast z wrażliwością tego rozwiązania na sprzęt i połączenie end usera oraz na ataki typu XSS. Aplikacja ma się charakteryzować przekonującym UX/UI, ale myślę, że dr Kruk będzie przywiązywał jeszcze większą wagę do aspektu "reliable" projektu.

W podejściu MPA wszystkie zmiany związane z rozszerzaniem strony o nowe komponenty lub funkcjonalności byłyby wprowadzane po stronie serwera. Zastanawiam się, czy wprowadzanie tych zmian po obu stronach w podejściu SPA byłoby bardziej bolesne, jeśli w podejściu SPA frontend i backend mogą być mocno niezależne od siebie. Mam wrażenie, że niekoniecznie, co przemawiałoby dalej na korzyść SPA, ale mogę się mylić.

Samodzielne tworzenie HTML-a vs szablony Bootstrap. Nudny i oklepany, ale ma naprawdę dużo gotowych komponentów do wykorzystania. Mogę być uprzedzony, bo akurat Bootstrap to jedna z niewielu rzeczy we froncie poza podstawowym HTML-CSS, które znam. :D

Na koniec: Zachęcam do dyskusji i krytyki, bo nie ukrywam, że w tym momencie czuję się trochę przeładowany informacjami i chyba potrzebuję spojrzenia z szerszej perspektywy.

[pktiuk]

@kamilwil
Dobra analiza.
Podział na 3 widoki wydaje mi się bardzo dobrym pomysłem. Będzie wtedy możliwe lepsze podzielenie pracy.

Wydaje mi się, że cały front mógłby być serwowany statycznie, strona domowa oraz strona logowania nie potrzebują żadnego zaawansowanego budowania. A co do strony użytkownika to moglibyśmy odpowiednio wszystko opakować w javascripta. Po zalogowaniu trzymalibyśmy sobie token oraz login użytkownika w ciasteczku. Moglibyśmy to potem wykorzystać do pobrania potrzebnych danych uzupełniających.

Dzięki statycznemu serwowaniu całej treści uprościlibyśmy prace nad frontem. Po stronie backendu wszystko będzie takie same, ponieważ serwis budujący HTML-a też musiałby wysyłać zapytania do innych mikroserwisów, aby zebrać potrzebne informacje do wyświetlenia.

[kamilwil]

@pktiuk Czyli w opcji, którą opisujesz, do wygenerowania server-side byłyby trzy HTML-e, z czego dwa statyczne (wizytówka i logowanie/rejestracja), a jeden wypełniany JS-em już po stronie serwera i przesyłany w całości do klienta (widok zalogowanego). Dobrze rozumiem?

EDIT: Czy wtedy nadal zostawiamy sobie furtkę do częściowego wypełniania JS-em po stronie klienta (np. na potrzeby interaktywnych elementów w widoku zalogowanego), czy staramy się uniezależniać klienta od jakiegokolwiek ładowania JS-a po swojej stronie?

[pktiuk]

@kamilwil
W mojej koncepcji wszystkie html-e byłyby plikami statycznymi, które byłyby w całości uzupełniane po stronie klienta.

[kamilwil]

Wnioski po spotkaniu 8.04.2022:

• idziemy w client-side rendering dla widoku zalogowanego, mikroserwis po stronie serwera nie będzie potrzebny, bo będzie komunikacja z API bezpośrednio od klienta
• trzeba określić ostatecznie, czy ma być SPA czy MPA (wziąć pod uwagę podział pracy w zespole - przy jednym pliku na całość może być trudniej)
• panel rejestracji nie będzie potrzebny, panel logowania może nie być potrzebny, jeśli będą tylko guziczki "Sign up with GitHub" (zainspirować się innymi stronami)
• przygotować powyższe oraz dodatkowe materiały i spotkać się z @KarolNiem, aby podzielić się pracą

[KarolNiem]

09.04.2022 - frontend spotkanie

SPA vs MPA - zdecydowaliśmy, że chcielibyśmy zastosować podejście MPA, które pierwotnie opierałoby się na 2 HTML-ach – widoku dla niezalogowanego użytkownika oraz użytkownika zalogowanego. W widoku zalogowanego chcielibyśmy mieć możliwość dodawania nowych HTML-i wprowadzających nowe funkcjonalności, np. Agregację danych z innych źródeł niż Github, ale w miarę możliwości chcielibyśmy trzymać się dodawania dodatkowych widoków (np. Uszczegóławiających dane) przez okna dialogowe zamiast osobnych widoków.

Podział prac:

Koncepcja wizualna - Kamil

HTML dla użytkownika niezalogowanego – Karol

HTML dla użytkownika zalogowanego – Kamil

Perspektywa prac:

Najbliższy tydzień - research i zorientowanie się w temacie.

Opracowanie koncepcji wizualnej

Deadline: czwartek 14.04.2022