[8773]

Mirki, piszę pierwszą restową aplikację w Javie + klient w Angularze. Mam już działający prototyp, ale napotkałem pewien problem. Otóż klient musi być dynamicznie aktualizowany co sekundę lub dwie na przykład. Mam powiedzmy pięciu klientów i każdy musi wyświetlić zmianę, którą wykonam na jednym z nich. Udało mi się to zrobić poprzez web workery - każdy klient co sekundę wysyła GETa do API, po czym następuje wyjęcie danych z bazy. I tu pytanie do Was - co jeśli będę chciał takich klientów mieć 50? Baza danych jest mała, ale boję się, że może nie wyrobić albo mogą powstać jakieś opóźnienia. Nigdy też nie wrzucałem na żaden serwer aplikacji, a chciałbym to zrobić. Czy do takiej ilości zapytań potrzebuję wydajnego (i drogiego) serwera? Jak to rozwiązać?
#java #programowanie #javaee #angularjs #js

[KurtRussell]

@8773: Może niech serwer wypycha zmiany do klientów wtedy, kiedy jest to potrzebne (bo np. został dodany rekord do bazy). Można to zrealizować za pomocą websocketów.

[8773]

@KurtRussell: To musi być REST, żadnych socketów niestety nie mogę użyć.

[rex1313]

@8773: Wydaje mi sie bez sensu odpytywanie serwera co sekunde, nawet jesli nie ma zmian. Marnotrastwo zasobow. Poczytaj o long pooling, albo postaw websocket. Wtedy zapytania do bazy beda dzialy sie tylko wtedy, kiedy beda potrzebne.

[8773]

@rex1313: Bez sensu, ale nie znalazłem póki co innego rozwiązania.

[KurtRussell]

No to niestety nic nie zdziałasz. REST jest z założenia bezstanowy i jednokierunkowy.
Swoją drogą to co widzi klient zawsze jest nieaktualne, bo wszystko co opuszcza transakcję stanowi tylko migawkę stanu systemu w danym punkcie czasu.

[rex1313]

@8773: Teraz doczytalem, ze nie chcesz uzywac websocketow. W takim wypadku long pooling powinien zalatwic sprawe. Generalnie klient jest caly czas polaczony do serwera i pobiera dane dopiero wtedy, kiedy ulegna zmianie. Osobiscie nigdy tego nie implementowalem ( uzywalem websocketa do aktualizacji w czasie rzeczywistym ), ale nie sadze ze jest to jakos super skomplikowane. https://www.pubnub.com/blog/2014-12-01-http-long-polling/ tutaj pierwsza z brzegu stronka o tej technice.

[8773]

@rex1313: Dzięki wielkie. Pewnie to właśnie to, czego potrzebuję. :)

[KurtRussell]

@rex1313: Long pooling nie jest RESTowym podejściem. Korzysta z tego samego protokołu ale nie spełnia jego założeń. Poza tym, to podejście może powodować pewne problemy, Większość serwerów HTTP ma ustawione timeouty na czas połączenia, więc jeżeli nie masz możliwości wyłączenia tej opcji (nie polecam) to okaże się, że zbyt długo zestawione połączenia będą po prostu zrywane.

[rex1313]

@KurtRussell: Przy long pooling stosuje sie technike heartbitow, wysylania pinga co okreslony czas, aby podtrzymac polaczenie, wlasnie ze wzgledu na timeouty. Ta technika jest uzywana w wiekszosci aplikacji wymagajacych aktualizacji w czasie rzeczywistym, np facebook itd.

[fegwegw]

@rex1313: @KurtRussell: POLLing, panowie, nie POOLing :)

[Jakr]

@8773: odpal soapui albo jmeter i zobacz co sie stanie

[macq]

@8773: AMQP as a Service :) wiem wiem - musi być rest ... gdyby jednak to polecam zapoznanie sie z https://www.cloudamqp.com/docs/android.html #asynchroniczne

[jazuu]

@8773: a nie mozesz polaczyc websocket+ resty skoro sie na nie tak uparles ?
przez websokety klient dostaje info ze sa zmiany i uaktualnia sie przez RESTa .

[8773]

@jazuu: To jest jakieś rozwiązanie, dzięki.

[nunczako]

@8773: jest taka nowość w HTML5 właśnie do tego celu, nazywa się "Server Sent Events", ale np. nie jest obsługiwane przez IE (z tego co pacze), więc jeżeli nie jest to problem to proponuję użyć tego. Pod spodem pewnie i tak robi okresowe odpytywanie, ale chodzi o to że API jest banalnie proste

[8773]

@nunczako: Sprawdzę, dzięki!

[p.....n]

@8773: REST się do tego nie nadaje. Albo websocket albo tzw. long polling po HTTP. Względnie odwracasz kolejność i zamiast pull robisz push do klienta (wykorzystując HTTP/2 możesz po prostu wypchnąć po połączeniu dane do klienta).

[nunczako]

@8773: aha, jak masz problem z wydajnością to po prostu musisz zrobić jakieś cachowanie, czyli zrobić zapytanie do bazy tylko za pierwszym razem a wynik zapisać w pamięci, następnie jak pozostali pytają o to samo to zwracać ten gotowy wynik