Architektura Aplikacji Webowej

Odpowiedz Nowy wątek
2017-01-10 22:22

Rejestracja: 3 lata temu

Ostatnio: 2 lata temu

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

edytowany 1x, ostatnio: ScuroGuardiano, 2017-01-11 00:54
Nie mogłem się powstrzymać przed podlinkowaniem tego : https://www.youtube.com/watch[...]page&v=HTgTZ8I5oug#t=1747 - jarekr000000 2017-01-11 08:54

Pozostało 580 znaków

2017-01-11 11:23

Rejestracja: 3 lata temu

Ostatnio: 3 godziny temu

Lokalizacja: U krasnoludów - pod górą

  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).
    1. I tu zawsze pytanie - na kiego grzyba Ci baza danych (ktoś od Ciebie tego wymaga ? ).

jeden i pół terabajta powinno wystarczyć każdemu
edytowany 4x, ostatnio: jarekr000000, 2017-01-11 12:27
Pokaż pozostałe 2 komentarze
Tzn to taka gra w której budujesz miasto, atakujesz innych, taka typical gra przeglądarkowa, jednakże ma mieć elementy real-time oraz chat. - ScuroGuardiano 2017-01-11 12:33
@ScuroGuardiano: real time - czy jak mnie ktoś atakuje to mam możliwość jakoś zareagować ? Czy to tylko powiadomienie - i już i tak nic nie zrobię ? - jarekr000000 2017-01-11 12:42
No tak, np. bez odświeżania strony dostaniesz komunikat, że idzie atak na Ciebie i sam system walki ma być real-time, tzn co 30 sekund jest rozgrywana runda walki i użytkownik może pomiędzy rundami zarządzać tą walką. - ScuroGuardiano 2017-01-11 12:48
@ScuroGuardiano: to websockety i Single page application Ci się sprawdzi. Ale temat niestety gruby. Zacznij od zrobienia PONGa, albo czegoś podobnego - wprawka się przyda zawsze - lepiej zepsuć na czymś małym po tygodniu, niż na czymś dużym po dwóch latach. - jarekr000000 2017-01-11 12:53
No te single page application mi się spodobało, scala.js też jak spojrzałem wydaje się bardzo fajne, dzięki za pomoc :D - ScuroGuardiano 2017-01-11 13:00

Pozostało 580 znaków

2017-01-11 14:13

Rejestracja: 4 lata temu

Ostatnio: 3 tygodnie temu

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.

Pokaż pozostałe 4 komentarze
A jakbym tak napisał w node.js serwer, który by komunikował się z serwerem gry za pomocą zwykłych socketów, a ze stroną w javascripcie używając websocketów, taki pośrednik? Opóźnienie by było jakieś 1-2 ms. Chociaż głupi w sumie wydaje mi sie ten pomysł, ale ostatnio na takie pomysły wpadam xD - ScuroGuardiano 2017-01-12 21:56
@ScuroGuardiano: nie jesteś dobry w JS to uważaj z nodejs. Opóźnienie to najmniejszy problem. To po prostu całkiem inny sposób myślenia niż znasz z C++. Ale uczyć się zawsze warto. - jarekr000000 2017-01-12 22:04
Chciałem coś napisać i pomyślałem, że fajnie będzie napisać taką grę, napiszę jej działanie w C++, a później pomyślę o napisaniu komunikacji sieciowej itd. No - jeśli masz grę jednograczową, to może być ją ciężko zamienić ją na multiplayer - LukeJL 2017-01-12 23:01
no chyba że już na starcie piszesz ją w architekturze, które potencjalnie może stać się multiplayerowa. - LukeJL 2017-01-12 23:02
Od razu ją piszę pod multiplayer, no coś takiego jak na przykład empire universe (podałem ten przykład, bo ta gra jest zrobiona w architekturze SPA) - ScuroGuardiano 2017-01-12 23:11

Pozostało 580 znaków

Odpowiedz

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