Architektura Aplikacji Webowej

0

Witam.
Z racji tego, że wszystko za co się zabieram chcę zrobić chociaż w 20% poprawnie chciałem się Was zapytać czy dobrze rozumiem architekturę aplikacji webowej, np. z tego obrazka title
Mianowicie ja to rozumiem tak:
Tworzę stronę (presentation layer) w JS, HTML, CSS i do jakichś tam drobnych operacji PHP/Python, albo serwer w node.js, whatever co się nadaje do zrobienia wyglądu strony
A całą logikę strony, czyli np. jakieś operacje skomplikowane, czytanie z plików, wysyłanie maili etc. robię w np. C++, Javie, Pythonie i realizuję komunikację między tymi dwoma modułami za pomocą np. socketu AF_UNIX

Czy to moje rozumowanie jest chociaż po części poprawne? Chcę poszerzać swoje horyzonty i dlatego pytam doświadczone osoby. Uczyłem się C++ i wszystko za co chcę się wziąć zaczynam od pisania mechaniki w cpp... Właśnie teraz robię projekt takiej gry przeglądarkowej (Wyjdzie za 5 lat xD) i od początku moim założeniem było połączyć ten serwer w cpp socketami z clientem na przeglądarkę i nie wiem czy to poprawne działanie...

Za odpowiedzi z góry dziękuję :D

2
  1. Zapomnij o tego typu obrazkach - bo to nic nie wnoszące pierdoły (polecam wideo).
  2. Co do architektury - wszystko zależy od tego jaką aplikację/grę chcesz napisać:
    generalnie im bardziej real time tym więcej kodu warto mieć w przeglądarce. Ja już dawno skręciłem w serverless (i to wcale nie przy grach...). Server zostaje tylko hubem komunikacyjnym.
    (zobacz np. jak działa Starcraft i battleNet :-) ).
  3. Poczytaj co to jest Single Page Application - moim zdaniem to najwygodniejsza architektura (czyli nie ma żadnego web server ,który generuje Ci html).
  4. Tu jednak taka uwaga - jeśli lubisz C++?Java i programowanie obiektowe- to ciężko będzie Ci pisać dużo kodu w JS - ja polecam ScalaJS :- jeśli jesteś twardy - lub TS : bardziej klasycznie.
  5. Co do socketów - to jak najbardziej polecam WebSockety - ale nie polecam gołej implementacji protokołu na Socketach IP. Połamiesz się na szczegółach. Czyli między serverem właściwym a stronką (żadnych pośrednich web server).
  6. I tu zawsze pytanie - na kiego grzyba Ci baza danych (ktoś od Ciebie tego wymaga ? ).
1

Tak, nie ma to działać na zasadzie przeglądarka -> serwer hostujący stronę -> serwer gry, tylko bezpośrednio przeglądarka -> serwer gry. Z 2 powodów:

  1. Zabierało by to za dużo czasu - pakiet danych musiałby być wysłany 2 razy, najpierw do serwera "od frontu" a potem z niego do serwera gry.
  2. Serwer "od frontu" nie spełniał by żadnego zadania - co miałby robić? Wszystkie obliczenia są po stronie serwera gry, on miałby jedynie zadanie przesłać to dalej co jest bez sensu.

Chyba że gra nie ma być real time. Wtedy również jedna aplikacja na serwerze do całej logiki biznesowej bez żadnych dodatkowych warstw. Jedynie zamiast websocket'ów możesz użyć zwykłych requestów.

Ogólnie jeśli ma to być realtime polecam do backendu node.js Ma bardzo dobre wsparcie asynchroniczności przez co większe obliczenia nie sprawią że dane przyjdą z opóźnieniem.

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